RE 


» TRICKS FOR REALISTAE 


» DESIGN DOCUMENTS? 
> \ ROADMAP FOR SUI 


=e . Bio enh ik? 
Izsv6 vo QUOONC 

V1 NOSTIM Z6z2>b 

89z0 SNDIS3ZG MOGVHS JD 71 


: : ce i137MOH NVG 
| q —— Z6 ONW OT96 OZT vOO AD ESTO66ETSS 


hina ..... 
(UN 


(s501"Or Sot 2s 
~ A MILLER FREEMAN PUBLICATION / dy www.gdmag.com : DISPLAY UNTIL SEPT. 8, 1997 


DS CANADA $6.95 
08> 





G0 AHEAD. 
~ SMOKE — 
OFFICE. 























«WE 











on mo 
7 e@ : ates 
FE 3 
a 
be os " 
P : Hes 
; 
3 
a 
ye 3 ’ PS iad 
a se 
3 5 s 
i, e i © mw & a ‘ 
ee id ia ae 
PS ‘ 
ff 
my set, 
<n. * isi 
vas 
oe 3 
: > A Be. 
2 a 4 : 3 
FE e a 5 
- ai, 
Be oy 2 
© ie ’ 






See Us at Booth #1353, 
August 5-7, 1997 
Los Angeles Convention Center 


“Robot” from “Pegasus 
Prime” © 1996 Presto 
Studios, Inc. 


Image from The Journeyman Project 3. © 1997 Presto Studios, Inc. 


“Norad Sub Room” from 
“Pegasus Prime” © 1996 
Presto Studios, Inc. A] 


The Dark Eye, Bad Mojo, Star Wars: Shadows of 


the Empire, QIN: Tomb of the Middle Kingdom, Gadget, The 
Journeyman Project: Buried In Time, The Resident’s Bad Day 


Image from The Journeyman Project 3. 
© 1997 Presto Studios, Inc. 





On The Midway, Prince Interactive, Iron Helix, Pegasus Prime. 


Broadcast Effects: ) Dateline NBC, X Files, Fox Television, 


Sci-Fi Channel, E! Entertainment Television, Nickelodeon, 
Babylon 5, Sliders, Star Trek: Deep Space Nine, The Real 





Adventures of Jonny Quest, JAG and many more.... 


New Decade # New Software © New Platforms Cena sa a RNC TE 

Powerful new features. Dazzling image quality. The world’s fastest renderer. Our CO 
first ten years were great — our next ten will be awesome. 

We're celebrating our diamond anniversary with new platforms (like NT and SGI ...), 
new products (like the modeler, radiosity ...) and more. Want the details? Check out our 
web site www.electricimage.com. 

For a free demo version of Electriclmage, call now (888) RENDER. 


Ne IM ~< See Ue Wee ea ie ci Bate 
“Moth Flight” From Bad Mojo™ and © Pulse Entertainment, Inc. 
All rights reserved. 


i momo eo a ee me = —- 
MacUser 
(3? AWARDS 
WORK HARD, RENDER FAST, RETIRE YOUNG.” Macworld ‘ face 


888 RENDER 1¢ sales@electricimage.com ® www.electricimage.com 
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“Electriclmage Broadcast delivers up to NTSC and PAL resolution for television, video and multimedia projects, and high resolution stills (up to 16Kx1 6K). Electriclmage and Work Hard, 
Render Fast, Retire Young are trademarks of Electric Image Inc. All other trademarks and copyrights are those of their respective holders. Specifications subject to change without notice. 
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26 The Artist Synapse 


Using a hypothetical Q&A between an RT3D artist 
and other team members, Josh White translates tech- 
nical requirements into artist-speak. 

BY JOSH WHITE 


42 Using Groupings for Networked 
Gaming 


Grouping allows networked games to route essential 
data among the players while making efficient use of 
both network and CPU resources. Jesse Aronson 
guides the reader through efficient data distribution. 
BY JESSE ARONSON 
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50 Using a Base-Root System for 
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Animated Characters 6 D->( tecaves® 


Give your character realistic movement by locking it into ‘ 
a real-world coordinate system. Zed’s not dead, baby! 


BY SCOTTI CORLEY 
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58 Creating a Great Design Document 


A first-class design document captures the body and 
soul of your game. Here’s how to ensure that your 
vision endures through the development cycle. 

BY TZVI FREEMAN 
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12 Graphic Content BY BRIAN HOOK 

Multipass Rendering and the Magic of Alpha Blending 

6 Game Plan BY ALEX DUNNE 

21 Artist’s View BY DAVID SIEKS 

Take Me Into the Ballgame 
64 Soapbox BY DANI B. BERRY 10 Bit Blasts 

Escaping the Solo Trap Provoking Microsoft, new Ray Dream Studio, wares 
COVER: The cover image was created by Pyros Pictures of for tracking your multimedia goods, Activex con- 
Newport Beach, Calif., in 3D Studio MAX 1.2 and composited in trols, and a 3D game builder from Switzerland. 


PhotoShop 4.0.1. It was originally created as a 30-second anima- 
tion for their own company logo. See http://www.grubba.com/pyros 
for more of their artwork. 
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Allow us to introduce you to Pyramid3D;" the most powerful 





















PC graphics processor in the world. 
Any world. 
’ < ~ You see, Pyramid3D produces the 
you've only seen on expensive 
workstations. That's because 
it uses a unique program- 
mable, optics-based 
architecture that 
treats light the same 
way nature does, 
with all the subtleties the 
human eye normally picks up. 


Which means you can now bring a whole 


OUR NEXT 
NTO A MO 


new world of reality to PC graphics. With advanced 








effects like radiosity, Phong shading, bump mapping, 
nonlinear fog and perspective-correct texture 
and color shading. 

All of which can be executed 

in real time. 

And unlike many chips 
that began as 2D accelerators, 

Pyramid3D was designed from 


the ground up as a 3D engine. 


So it's easier to program. And it runs faster than /, \ 


a raptor on steroids. 


3D 


in at a whopping 1 million triangles/sec* All with a fill rate of 


Games and professional animations clock ram 


up to 50 million pixels/sec. 





3Dlabs 

Tritech 3Dfx REAL3D GLINT Gamma 
REALITY CHECK Pyramid3D VooDoo Rush R3D100 + Permedia 
Radiosity Texturing * * "A 
Phong Enhanced Texturing ** Jo 
Bump Mapping / 
Non-linear Fog / 
Perspective-Correct Texture, Jo 


Color, Fog, Transparency 


Direct3D API, OpenGL & 
Heidi Support 


NS 
SS 
a 
Ss 


Independent Colored Highlights 
Multiple Independent Textures ** 


Object/Vertex Level Processing 


~~ & S&S & 
~ 


Symmetric Multiprocessor 
Scalability (2 to 10 Processors) 


2D/Video Acceleration J / 


24-bit Z buffer depth "A J 






It's also compatible 
with Direct3D™ 

and OpenGL" for 
Microsoft® Windows® 
platforms. 

But this is just a preview. Get the big picture at 
www.tritechmicro.com/p3d. Or call 1-888-253-8900, 
Ext. 304, to qualify for our design kit. 
We'll help you find a whole new 


Tritech 


audience for your work. 


*25-pixel point-sampled textured Gouraud shaded z-buffered triangles 


©1997 Tritech Microelectronics Inc. All rights reserved. Pyramid3D, the Pyramid3D logo and the TriTech logo are trademarks of Tritech Microelectronics 
All other trademarks and registered trademarks are the property of their respective holders. Deinonychus by Steven Czerkas © 1989 


Microelectronics ., 








Debabelizing Development 


easoned software developers 
have likely heard of Fred 
Brooks’ book, The Mythical 
Man-Month. In his book, 
Brooks forwarded the notion (now 
commonly accepted as gospel) that 
adding developers to a project already 
behind schedule can backfire. New 
people require time and training to get 
familiarized, which requires time and 
energy from the team members already 
on the project. So while the productive 
team members spend their time brief- 
ing the newest people on the project, 
coaching them, overseeing their work, 
and so on, less work gets done than it 
would otherwise. One of the lessons 
that developers and project managers 
should glean from this is that good 
communication comes at a cost. 

Certainly, game development is not 
immune to the scenario that Brooks 
described, and in fact, game develop- 
ment is more prone than most software 
development projects to suffer from 
carelessly adding staff without consid- 
ering the consequences. Brooks’ revela- 
tion is all the more interesting when 
you consider that when The Mythical 
Man-Month was published in 1975, 
computer games were largely unknown 
to the general public. Computer enter- 
tainment consisted primarily of 
Wumpus hunting and playing PONG. 
Game development didn’t require the 
intense collaboration between design- 
ers, artists, writers, producers, program- 
mers, music composers, audio effects 
engineers, and the rest of the special- 
ties that we see in game development 
today. However, now the industry 
relies on leading-edge technical knowl- 
edge and creative input, so good com- 
munication between team members is 
arguably the most important input in 
game development today. 

The most often cited communication 
gap in game development is the one 
separating programmers and artists/ani- 
mators. Since these two groups make up 
the lion’s share of today’s game devel- 
opment teams, it’s only natural that 
misunderstandings will occur more fre- 
quently at this junction. 

Fortunately, almost all of the pro- 
grammers and artists/animators that 
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I’ve met understand the importance of 
communicating with one another. This 
was reconfirmed for me at the CGDC 
last spring when we held two focus 
groups, one for artists/animators and 
one for programmers. In each session, | 
asked whether there was a problem 
dealing with the other group. While 
people in both groups said that inter- 
disciplinary communication was chal- 
lenging, everyone agreed that getting 
artists, animators, and programmers to 
see eye to eye was one of the challenges 
that made game development reward- 
ing. When everyone made an effort to 
teach and learn from each other, the 
quality of the game benefited tremen- 
dously. One point that has stuck with 
me was the interest on the program- 
mers’ part to educate artists and anima- 
tors about programming concepts, 
since that was often a bottleneck in 
their communication. 

(Incidentally, it’s important to note 
that having good communication 
doesn’t imply that there won’t be con- 
flict between team members. In one of 
my favorite software development 
books, Dynamics of Software 
Development, Jim McCarthy makes this 
excellent point: “The only consensus 
[between team members] worth having 1s 
a creative one achieved in the combat of 
fully engaged intellects.” In other words, 
sometimes developing a great product 
requires conflict between team mem- 
bers in order to release the maximum 
amount of creativity.) 

Which brings us to Josh White’s fea- 
ture this month. Josh is the rare artist 
and animator who understands a great 
deal about the programming side of 
the equation. That gives him special 
insight into game development and it’s 
what makes his article significant to 
artists, animators, and programmers. 
Whether you’re in one group or anoth- 
er, you'll learn something from his 
peek into the psychology of each group 
and come away with a better under- 
standing of how both groups translate 
technology into their own terms. 
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3D PROGRAMMING TECHNIQUES 
GAME DESIGN 

GAME TESTING 

ART AND ANIMATION 
DEVELOPING NETWORK-BASED GAMES 
SOUND DESIGN 

DIGITAL ASSET MANAGEMENT 


The Full-Om Writers « 


NOAH FALSTEIN 
SID MEIER 

CHRIS HECKER 
DAVID SIEKS 
NOLAN BUSHNELL 
CHRIS CRAWFORD 
BRIAN HOOK 

BEN SAWYER 
ANDRE LAMOTHE 


Front Page Newa « 


EVERY MONTH OUR COVER WILL FEATURE ART 
FROM A TALENTED GAME ARTIST. 


Cool! 
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Pts. 


You are if you're reading 

Game Developer magazine. 

We got a makeover, we've gone 
monthly, we're free if you qualify — 


and we're still way deep! 


Find even more hardcore technical 
coverage on programming, 3D and 
visual design, sound design, and 
game design strategy in Game 
Developer. \t has everything your 
entire professional team needs to 


bring killer games to market. 


Game Developer is FREE to any member of 
the professional game development team! 
Call 800.250.2429 or stop by www.gdmag.com 
and fill out the qualification form for your free 


subscription today! 


rend ON THE FRONT LINE OF GAME INNOVATION 




















Don't Let Go the Code 


‘ma “from the first issue” reader of 

Game Developer. | must say this mag- 
azine has grown in the right way, and 
it’s very useful in my game program- 
ming work. I also liked the new design 
and your motivations for changing the 
magazine, but I must admit I was a lit- 
tle disappointed in not seeing a single 
technical article. Please don’t do so! 

As an old reader I’m pleased that 
others involved in game developing 
could find your magazine new and 
interesting (artists, designers), but 
programmers would die without a 
line of code or some technical hints. 
You know how weird we game devel- 
Opers are... 

STEFANO BARALDI 
ITALY 


EDITOR ALEX DUNNE RESPONDS: 

Don’t worry about technical content. !n ret- 
rospect, it probably wasn’t smart of us to 
schedule an issue on game design that 
coincided with our relaunch. The lack of 
code was more coincidental than a planned 
change in direction away from program- 
ming topics. True, we are covering more 
topics other than programming (such as 
design, QA, art/animation, and project man- 
agement), but we don’t want to alienate our 
core readership either. 

Our June 1997 issue featured an article 
about pathfinding Al, this issue has article 
on networking and programming for 3D ani- 
mation, inimitable 3D programmer Brian 
Hook has joined us as a columnist, and 
upcoming issues have other programming 
articles as well, with code. 


Wherefore the Mac? 
: saw your magazine for the first 
time this month in a shop here in 
Sweden. As far as I know, it’s the only 
one that addresses game develope- 
ment issues. I’m very interested by 
what I saw in the April/May 1997 
issue. I would like to know if you 
cover Macintosh game programming, 
too. I’m very aware of how poor the 
Macintosh game programming world 
is when compared with what’s avail- 
able for PCs, so I would not be very 
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surprised if you did not devote too 
much space to it. 
PEIRANO PHILIPPE 
AXXORN, SWEDEN 


EDITOR ALEX DUNNE RESONDS: Yes, 
the Macintosh market has dwindled to a sec- 
ondary market for most game developers 
who still support it. If Apple can turn its plat- 
form around, you can be sure that you’ll see 
coverage in GD. My heart goes out to Apple 
and all Mac users, but only time will tell 
whether games+Macintosh=developer $$. 


Who Are We? 


have seen somewhere that Game 

Developer is now a monthly maga- 
zine. Is this true? [ haven't yet seen the 
April/May 1997 issue, so I don’t know 
what changes have been made to the 
magazine; I hope that it continues its 
already great tradition of bringing 
timely information and articles on 
game development. 

Another question: Who, in your 
personal opinion, are the main read- 
ers of GD? Also, how do you view the 





is a challenge to hit the right level. |!am 
trying to target people that develop 
games professionally, not beginners. 
However, since the professionals are gen- 
erally so advanced that to keep them 
interested might take extremely technical 
articles (which then would only appeal to 
a small section of our readers — those 
who actually understand concepts like 
triple-buffered sound layering), | shoot for 
articles that are technical but can be 
understood by a wider audience. Of 
course, by being less technical, some 
readers won’t be as interested. 

Now | know how politicians feel when 
they try to please everyone — it just can’t 
be done. You have to pick a path and stay 
on It. 


New to Scene 
esterday I read your magazine 
(April/May 1997 issue) for the 
first time — and I liked it very 
much. I have no previous magazines 
of yours to compare this issue with, 
but pees from Bhat & issue and the 























level of content, meaning, do yc 
think that the articles are to 
cal or too introductory (but I 
this has to be balanced with > 
specific people Game Develc 
is targeting). Frankly, I 
wish Game Developer 
would become more 
technical and 
advanced-developer 
oriented. Then again, I 
guess it already is, and | would | 
to have to read about triple-buff 
sound layering (a term I just made 
up) without reading some introduc- 
tory material first. 

I guess it’s quite hard juggling and 
compromising between content depth 
and breadth. Anyways, you guys are all 
doing a great job! 

SANG WoO HAN 
SOUTH KOREA 


EDITOR ALEX DUNNE RESPONDS: /’l! 
look into what happened to your April/May 
issue. You should have received it by now! 
Regarding the balance between techni- 
cal and introductory material, it definitely 
























rs, graphic artists, 
and sound 
engineers/ 
musicians 
and the rest 
© of the “sup- 
- porting cast” 
get some very well 
served considera- 
ive I read things like, 
really made some cool 
graphics. ” T recognize that coders 
can have a big say in the quality of 
the graphics, but often graphic 
artists aren’t mentioned at all. Also, 
the articles were good. “Designing an 
Effective Interface,” “Determining 
Your Game’s Audio Requirements,” 
and the Artists View “Different 
Perspectives on 3D Sprites” were well 
written and documented, and even 
funny at times. 

So, here’s to the future! Keep up the 
good work! 

Dennis W. Hansen 

Via e-mail 
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FIRE GL 1000 WINDOWS NT ACCELERATOR. now you don’t need a 


workstation to create workstation-quality graphics. Diamond Multimedia’s affordable 
new Fire GL 1000 brings the ultimate in 2D, 3D, and video acceleration to your 
Windows® NT desktop. It provides fast texture nike} 9) o)iay-aurolaremmere)ole) (sr o)lir-lelal-eeer-lave! 
supports the OpenGL, Direct 3D, and Heidi 3D APls—for all your animation, authoring, 
and CAD applications. So visit us at www.diamondmm.com/firegl for all the facts and 


the location of your nearest Diamond reseller. Then just imagine what you can do. 





Use your 


imagination. 
(Not a 
high-priced 


workstation.) 





Visit us at www.diamondmm.com/firegl for a chance to wina 
Fire GL 1000 accelerator! 


DIAMOND 


MUtkLTtiM €E€ DI A 


All trademarks are the property of their respective owners. ©1997 Diamond Multimedia Systems, Incorporated. All rights reserved. 


Accelerate your world. 
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INDUSTRY 
WATCH 


by Ben Sawyer 


BANDAI HAS CALLED OFF the merger 
between itself and Sega; middle managers 
at Bandai supposedly rejected the idea on 
the grounds that it didn't make any sense. 
It's hard to figure out where Sega rebounds 
from here. Already Peter Loeb, one the 
powers behind Heat, Segasoft's online 
gaming network, jumped to EA to head up 
its emerging online plans. 

SPEAMING OF EA, the company has also 
hired two Virgin managers for Origin. Neil 
Yong and Chris Yates, two former V.P.s of 
technology, operations, and product devel- 
opment, left Virgin only to surface at Origin. 
Origin has had a lot of trouble lately losing 
key staff and is going through some restruc- 
turing, all while trying to get Ultima IX and 
the long-awaited Ultima Online out the door. 

EA's news didn't stop at new executives 
either. On the heels of recent investments 
in both Mpath and Accolade, EA announced 
that it would absorb Maxis in a merger val- 
ued at $125 million. The merger values EA 
at nearly $1.8 billion. Reaction seems good 
given the forecast that EA will wring more 
out of the Sim product line on a worldwide 
basis than the current $50 million in sales 
that Maxis has. 

In other EA news, it announced, along 
with Microsoft, support for ICTV, a new set- 
top box technology that allows users to play 
online games run from remote PC servers 
over their cable TVs. This is a significant lit- 
tle piece of news. EA is especially hardcore 
about platforms they choose to support. It's 
rarely been wrong in its platform support, 
jumping on the Amiga, pulling out of 3D0, 
and propelling the Genesis to stardom. 
Could it be right again? Microsoft seems to 
thinks so. This development has people 
buzzing. Trials continue in San Diego. 

IS THERE A SPIN-OFF inthe midst? 
CUC announced a $22 billion merger with 
HFS International. CUC, which owns Sierra, 
Davidson, Knowledge Adventure, Blizzard, 
Berkeley Systems, Papyrus, and others, has 
cobbled together a huge number of game 
companies. However, the CUC also has a 
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A Call to Microsoft 


AN IMPRESSIVE LIST of game 
developers released an open 
letter to Microsoft Corp. 
calling on the com- 
pany to actively 
support the 
OpenGL 3D API 
for games on 
Windows 95 and 
Windows NT. The 
letter makes it clear 
that game developers 
want the option of using 
OpenGL, and they want 
Microsoft to work with them Se ee 
to provide OpenGL on its plat- Ye 
forms. 

John Carmack, technical director 
of id Software, has made no secret 
of id’s commitment to OpenGL. “The 









VideoSoft VSDirect 


UK-BASED COMPONENTSOURCE 
has made available VSDirect, a set of 
ActiveX controls that facilitates the use 
of DirectX technology from within 
Visual Basic 4.0 and 5.0. An earlier ver- 
sion of VSDirect was previously sup- 
plied by MicroHelp under the name 
MicroHelp Game and Multimedia 
Xponents. 

VSDirect contains numerous multi- 
media component features such as 
VSDirectDraw, VSDirectSound, and 
VSDirectPlay. VSDirectDraw works 
with interfaces that accelerate anima- 
tion techniques through direct access 
to video memory and hardware. 
VSDirectSound allows hardware and 
software sound mixing and playback. 
VSDirectPlay enables connectivity of 
games Over a modem link or network. 

VSDirect is available for Windows 95 
and Windows NT 4.0 or higher and is 
priced at approximately $195 (£120), 
with specially priced multi-user site 
licenses available for corporate or 
developer teams. An upgrade of 
MicroHelp Game and Multimedia 

















best thing Microsoft could do for the 


game community would be to 
release the Windows 95 OpenGL 
MCD framework to allow hard- 
ware vendors to easily build 
robust, full featured drivers. 
Without Microsoft's help, 
there will be several par- 
tial implementations to 
satisfy specific require- 
ments, resulting in 
version problems 
and incompati- 
bilities. The 
strengths of 
OpenGL are 


much better if Microsoft 
cooperated.” 


Xponents to VSDirect is available for a 
special price of about $30 (£20). 
®@ ComponentSource 

Berkshire, United Kingdom 

+44 (0) 118 958 1111 

http: //www.componentsource.co.uk 


Media Manager 


LUMINOUS TECHNOLOGY CORP., 
has announced the availability of the 
Luminous Media Manager content man- 
agement system. This digital asset man- 
agement system runs on industry stan- 
dard Open Database Connectivity 
(ODBC) compliant databases that can be 
accessed from any operating platform, 
scaled to add processing power and sys- 
tem resources as needed, and extended 
with additional functionality from third- 
party tools. Using 14 customizable fields, 
Media Manager software customers can 
catalog and track file types including 
images, illustrations, digital sounds, 
QuickTime movies, text, and other digi- 
tized media over networks, the Internet, 
or enterprise-wide intranets. 

Media Manager uses a plug-in archi- 
tecture for its “I-Pieces,” which gener- 
ate thumbnails and previews of many 


http://www.gdmag.com 


a . ee a | 


O F 


file types, including TIFF, PICT, EPSF, 
GIF, JPEG, QuickTime, and Mac OS 
sound files. Third-party developers can 
develop custom applications for cur- 
rent and future media formats with the 
Media Manager API. 

Media Manager runs on MacOS or 
Windows servers. Users can access the 
database from MacOS, Windows 95, or 
Windows NT workstations, or through 
a web browser. A Media Manager 
Cross-Platform MacOS/Windows NT 
Server Kit is available for the introduc- 
tory suggested retail price of $3,495, 
which includes five client licenses. 
Additional client packages are available 
on the MacOS platform or Windows 
operating system for suggested retail 
prices of $995 for five clients, $1,795 
for 10 clients, and $3,795 for 25 
clients. Site licenses are also available. 
‘M® Luminous Technology Corp. 

Seattle, Wash. 

(206) 689-6309 

http://www.luminous.com 


Ray Dream Studio 5 


METACREATIONS has announced the 
latest version of its 3D design and ani- 
mation tool, Ray Dream Studio 5. This 
release features new object creation 
tools, new rendering effects, interface 
improvements, and support for MMX 
and symmetric multiprocessing (SMP) 
technology. 








Vertex-level modeling has been 
implemented in the Mesh Form 
Modeler. ThinkFish LiveStyles lets users 
apply 2D hand-drawn looks to 3D 
objects, so images and animations ren- 
dered with the Natural Media renderer 
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can resemble cartoons, paintings, or 
sketches. The animation toolset has 
been expanded to include collision 
detection and other physically based 
behaviors. Plus, Ray Dream Studio 5 
comes with over 850 Dream Models cre- 
ated by Acuris and Viewpoint Datalabs, 
SOO shaders and textures, and hundreds 
of preset camera and light configura- 
tions, as well as presets for behaviors, 
deformers, links, and render effects. 

Ray Dream Studio 5 is available for 
MacOS, Windows 95, and Windows 
NT. The suggested retail price is $449. 
Upgrade price is $99. 
™ MetaCreations 

Scott’s Valley, Calif. 

(800) 846-0111 

(408) 430-4000 

http://www.metacreations.com 


3D Game Machine 


VIRTUALLY UNLIMITED has released 
version 2.0 of its 3D Game Machine 
framework for Windows 95, Windows 
NT, and MacOS. 3D Game Machine 
(3DGM) is a specialized game develop- 
ment tool, featuring a highly opti- 
mized core with a straightforward 
C/C++ API, as well as visual tools. Full 
integration with Kinetix 3D Studio 
MAX is provided through its 3DGM 
Factory interactive modeler, and the 
3Dfx Voodoo is directly supported. 

The 3DGM Factory lets artists to 
import animated 3D models for 
immediate integration into their 
game. Factory’s groupware features 
organize the team’s work for accurate 
asset tracking and automatic project 
updating as new 3D models and tex- 
tures are added. 

3D Game Machine 2.0 is licensed on 
a zero-royalty, per-application basis, 
priced at $14,750 for Windows 95 and 
Windows NT, and $7,750 for MacOS. 
An evaluation version of the 3DGM 
package is also available. 
® Virtually Unlimited 

Geneva, Switzerland 

(+4122) 700-7170 

laurent@virtually3d.com 

http://www.virtually3d.com 
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huge business running affinity programs 
and is especially big in the travel and ser- 
vices business. Now that it is merging with 
HFS, it is an even bigger travel and services 
company that includes Avis Car Rental, 
Days Inn, Howard Johnson, Coldwell 
Banker, Century 21, Ramada, and more. 

Ken Williams, founder of Sierra, will be 
named vice chairman of the corporation — 
now we know the real meaning behind 
“King's Quest.” While the market awaits 
the final details of the combined company, 
speculation is that the software companies 
will be spun off within a couple of years. 
Much will depend on how HFS stockhold- 
ers and executives react. Other than 
Leisure Suit Larry becoming a new hotel 
mascot, there just doesn’t seem to be much 
synergy here — as if there really was any. 
FINALLY, BRODERBUND is trying to 
better define its commitment to the gaming 
market on which it was founded. The com- 
pany has consolidated its gaming products, 
including Riven, the sequel to Myst, under 
its new Red Orb label. Red Orb also 
announced that it had signed Trilobyte to an 
exclusive distribution agreement. Joining 
Trilobyte and Cyan in producing games for 
Red Orb are SSG, Presto Studios, Smoking 
Car Productions, and Raven Software. Red 
Orb will develop in-house as well. 

NEWS RESOURCE OF THE MONTH. 
Are you using Pointcast 
(www.pointcast.com), Microsoft Investor 
(www. investor.com), or Mercury Mail 
(www.mercurymail.com) to track the stocks 
and news of public game companies? This 
month, | thought I'd include the symbols of 
all the relevant companies that | track. 


@ 


AKLM Acclaim Entertainment 

ATVI Activision 

BROD Broderbund 

CU CUC International 

ERTS Electronic Arts 

GAME Gametek 

GTIS GT Interactive Software 

NTDOY Nintendo 

SEGNY Sega Enterprises 

SEVL Seventh Level 

SNE Sony Corp. 

SBYT Spectrum Holobyte 

SP Spelling Entertainment 
(Virgin) 

THDO 3D0 Company 
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Multipass Rendering and 


the Magic of Alpha Blending 





talked about the architecture of id 
Software’s QUAKE, and one of the tech- 
niques he described was GLQUAKE’s use 
of multipass rendering. So since it 
seems like this is going to be a hot 
topic for a while, I thought I’d explore 
the subject. 

Multipass rendering is the technique 
of rendering a scene multiple times 
into the frame buffer, combining each 
rendering pass with the prior one to 
achieve interesting image composition 
effects. For example, you could multi- 
ply the passes together, or add them, or 
do a weighted blend on them, or what- 
ever. What you do between passes is 
limited only by the breadth of your 
imagination, the speed of your hard- 
ware (multipass rendering’s viability 
with a software renderer is doubtful, so 
I’m assuming hardware acceleration is 
present), and the flexibility of your 
API. Later on, I’ll talk about specific 
effects that you can achieve with mul- 
tipass rendering, but first we need to 
devise a way of combining our multi- 
ple passes together. 


tion, RGB frame buffers, and texture 
maps. Consider this fair warning. 


Te ee — a we —— —— eee ee 


A Crash Course on Alpha Blending 


7 multipass rendering to work, we 
need a way to combine, at each 
pixel, what is already in the frame butfer 
with the incoming color. This incoming 
color (sometimes referred to as the frag- 


he 1997 Computer Game Developers Conference just came and went, 
and I’m typing this as I recuperate from its effects on my voice and 
health. This year’s CGDC was pretty neat, and as always one of the high- 


lights of the show was Michael Abrash’s annual lecture. This year, he 


THEORY OF ALPHA BLENDING. Combining a 
fragment color with an existing pixel is 
such a useful operation that most major 
3D graphics APIs support it in one form 
or another, usually using the moniker 
“alpha blending.” Alpha blending com- 
bines a fragment color with the existing 
pixel color (Equation 1). 

Sf and Df are our source and destina- 
tion factors, respectively; 


Multipass rendering is the technique of 
rendering a scene multiple times into the 
frame buffer, combining each rendering pass 
with the prior one to achieve interesting 
image composition effects. 


ment color) is generated by applying 
texture mapping, lighting, filtering, and 
fog to your scene. Thus, the fragment is 
effectively the undithered color that we 
want to store into the frame buffer 
while rasterizing a primitive. 


EQUATION 1. The alpha blending operation. 





final.color = fragment.color * Sf + pixel.color * Df 


A quick side note: I’m not going to 
spend too much time worrying about 
software rendering or paletted rendering 
tricks, since that’s “old tech.” My 
columns will concentrate on advanced 
techniques that leverage hardware accel- 
erators that use RGB rendering. So unless 
something freakish happens, it is highly 
unlikely that I will discuss techniques 
that don’t rely upon hardware accelera- 
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EQUATION 2. Turning off blending. 





final.color = fragment.color 


fragment.color is the RGB color of our 
incoming fragment; and pixel.color is 
the RGB color of the pixel already in 
the frame buffer. 

Tables 1 and 2 show the wide variety 
of possible source and destination fac- 
tors. Note that these tables are not nec- 
essarily all encompassing — with 
OpenGL, for example, it’s entirely pos- 
sible that a vendor could implement 
new factors or even new blending 
equations (perhaps subtraction opera- 
tions) through the OpenGL extension 
mechanism. 

The mechanics of alpha blending is 
a lot to digest at once, especially since 


EQUATION 3. Source factor of 1.0. Destination factor of 0.0. 





final.color = fragment.color = fragment.color * 1+ pixel.color *o 
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a lot of blending modes aren’t particu- 
larly intuitive. Equation 2 shows a sim- 
ple example of how to turn off blend- 
ing mathematically by collapsing 
Equation 1. 

Easy enough! We don’t want the 
pixel color to contribute at all, and we 
want the fragment color to flow 
through unmodified. So a source factor 
of 1.0 and a destination factor of 0.0 
should give us Equation 3. 

Again, pretty simple. By using differ- 
ent source and destination factors, we 
can create a wide range of effects, 
including translucency, “dark maps,” 
dark maps mixed with Gouraud shad- 
ing, and specular lighting. But before 
getting into too much detail, let’s go 
over how OpenGL and Direct3D sup- 
port alpha blending. 

ACCESSING BLENDING THROUGH OPENGL. 
OpenGL’s interface to alpha blending 
is embodied in only four functions: 
glEnable, glDisable, glBlendFunc, and 
glTexEnv. To enable and disable alpha 
blending, you call glEnable and glDisable, 
respectively, with the parameter 
GL_BLEND. Once you’ve enabled blending, 
you Call glBlendFunc to specify your 
source and destination factors. Finally, 
glTexEnv specifies the method by which 
OpenGL will compute the source alpha 
factor when texture mapping is 
enabled (if texture mapping is not 
enabled, OpenGL will just use the 
alpha value iterated over the primi- 
tive’s surface). 

Since OpenGL specifies that alpha 
blending must be supported, you can 
just go ahead and use it without too 
much hassle. A caveat: If the underly- 
ing hardware doesn’t support alpha 
blending or a particular set of blending 
factors, then an OpenGL implementa- 
tion will fall back to a software-render- 
ing implementation. If you’re only ren- 
dering very few and/or very small 
alpha-blended polygons, then software 
rendering may not have a significant 
impact on performance. If you’re doing 
multipass rendering, however, this fall 
back could be a killer. 

ACCESSING BLENDING THROUGH DIRECT3D. Not 
surprisingly, Direct3D’s mechanism for 
controlling blending bears a striking 
resemblance to OpenGL. Blending is 
enabled and disabled by setting the 
D3DRENDERSTATE_ALPHABLENDENABLE state token 
to TRUE and FALSE, respectively. The 
source and destination factors are con- 
trolled by the D3DRENDERSTATE_SRCBLEND and 
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TABLE 1. Source Factors. 


OpenGL Constant D3D Constant 
GL_ZERO D3DBLEND_ZERO 
GL_ONE D3DBLEND_ONE 


GL_DST_COLOR 
GL_ONE_MINUS_DST_COLOR 
GL_SRC_ALPHA 
GL_ONE_MINUS_SRC_ALPHA 
GL_DST_ALPHA 
GL_ONE_MINUS_DST_ALPHA 
GL_SRC_ALPHA_SATURATE 


D3DBLEND_DESTCOLOR 


D3DBLEND_SRCALPHA 


D3DBLEND_DESTALPHA 


D3DBLEND_INVDESTCOLOR 


D3DBLEND_INVSRCALPHA 


D3DBLEND_INVDESTALPHA 
D3DLBEND_SRCALPHASAT 








Factor’s Value 

O 

1 

pixel.color 

1 - pixel.color 

fragment.alpha 

1 - fragment.alpha 

pixel.alpha* 

1 - pixel.alpha* 
min(fragment.alpha,1-pixel.alpha)* 


*assumes the existence of an alpha channel in the frame buffer. 


D3DRENDERSTATE_DESTBLEND state items. 
Finally, the interaction of texture map- 
ping and blending when computing 
source alpha is controlled by the D3DREN- 
DERSTATE_TEXTUREMAPBLEND state token. Like 
OpenGL, Direct3D uses interpolated 
alpha when texture mapping is dis- 
abled (when D3DRENDERSTATE_TEXTUREHANDLE 
is NULL). Currently, the derivation of 
source alpha in certain cases (for exam- 
ple, D3DTBLEND_COPY when no texture 
alpha is present) is inconsistent across 
shipping Direct3D drivers. When cod- 
ing to Direct3D, be sure to keep handy 
as many hardware accelerators as possi- 
ble so you can get a feel for how a cer- 
tain feature is being interpreted by 
hardware driver writers (don’t you just 
love this?). 

Note that because Direct3D doesn’t 
guarantee any functionality from a par- 
ticular driver, you must verify the 
availability of alpha blending and the 
specific blending factors you intend to 
use; otherwise, the output generated 
may be unexpected. Unlike OpenGL, if 
some effect — such as alpha blending 
— isn’t supported by a driver in 
Direct3D, you'll be forced to either 
eschew that feature altogether or 
implement it yourself; neither option is 
particularly enticing. 


TABLE 2. Destination Factors. 


OpenGL Constant D3D Constant 
GL_ZERO D3DBLEND_ZERO 
GL_ONE D3DBLEND_ONE 


GL_SRC_COLOR 
GL_ONE_MINUS_SRC_COLOR 
GL_SRC_ALPHA 
GL_ONE_MINUS_SRC_ALPHA 
GL_DST_ALPHA 
GL_ONE_MINUS_DST_ALPHA 


D3DBLEND_SRCCOLOR 


D3DBLEND_SRCALPHA 


D3DBLEND_DESTALPHA 


D3DBLEND_INVSRCCOLOR 


D3DBLEND_INVSRCALPHA 


D3DBLEND_INVDESTALPHA 


Cool Effects 


kay, here’s the meaty part: cool 
things that you can do with mul- 
tipass rendering. I’m just touching on 
some of the effects that I’ve been 
exposed to over the years. I’m sure 
developers will come up with some 
pretty wacky uses for blending that | 
can’t even comprehend right now, but 
this should get you started. 
TRANSLUCENCY. When developers hear 
the phrase “alpha blending,” the 
first effect that usually pops to mind 
is translucency — the ability to see 
partially through a surface. 
Translucency has many obvious 
uses. 
e Rendering glass, plastic, and other 
translucent materials 
e Glass reflections 
¢ Heads-up displays (HUDs) 
¢ Logos, symbols, or text overlays on 
the screen for things like copyright 
and disclaimer information 
e Map overlays 
e Lens-flare effects 
e Shield effects 
e Water 
We control a surface’s translucency/ 
opacity by using the fragment’s alpha 
value as a blending factor (Equation 4). 








Factor’s Value 

O 

1 

fragment.color 

1 - fragment.color 
fragment.alpha 

1 - fragment.alpha 
pixel.alpha* 

1 - pixel.alpha* 


*assumes the existence of an alpha channel in the frame buffer. 
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UATION 4. Using fragment’s alpha value as a blending factor. 





final.color = fragment.color * a+ pixel.color * (1 _ a) 


LISTING 1. OpenGL version. 


glEnable( GL_BLEND ); 





glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ); 


glTexEnv( GL_MODULATE ); 


LISTING 2. Direct3D version. 





pDev->SetRenderState( D3DRENDERSTATE_ALPHABLENDENABLE, TRUE ); 
pDev->SetRenderState( D3DRENDERSTATE_SRCBLEND, D3DBLEND_SRCALPHA ); 
pDev->SetRenderState( D3DRENDERSTATE_DESTBLEND, D3DBLEND_INVSRCALPHA ); 
pDev->SetRenderState( D3DRENDERSTATE_TEXTUREMAPBLEND, D3DTBLEND_MODULATELALPHA) ; 


The source alpha component (a) 
controls the weighting between the 
pixel and fragment colors. Using the 
alpha blending configuration from 
Equation 4, as source alpha varies from 
1.0 to 0.0, a surface will become gradu- 
ally more transparent. 

The OpenGL code in Listing 1 will 
enable blending for translucency 
effects, and will compute source alpha 
as the product of vertex and texture 
alpha (note that if there is no alpha in 
the texture, then texture alpha will 
implicitly be 1.0). An important point 
is that both Direct3D and OpenGL use 
the term “modulate” to mean “multi- 
ply.” I don’t know why this is, other 
than “modulate” sounds cooler than 
“multiply,” but you should be aware of 
this peculiar terminology. 

Listing 2 is the Direct3D 
DrawPrimtive analog of the previous 
OpenGL code. (From now on, I'll be 
using the DirectX 5 DrawPrimitive- 
style Direct3D code snippets, mostly 
because execute buffers are absolutely 
awful for doing code fragments.) 

To achieve correct output, an appli- 
cation has to render translucent objects 
in back-to-front order. Otherwise, near- 
er translucent surfaces won’t correctly 
blend with more distant surfaces. 

DaRK Maps. One of the coolest uses of 
alpha blending is for multipass dark 
maps. A dark map, commonly referred 
to as a light map (I'll explain why | 
use the term “dark map” later), is a 
texture map used to represent areas of 
shadow and light cast on a surface, 
independent of the underlying surface 
material’s base texture. Dark maps 
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allow for far more striking lighting 
than the more traditional per-vertex 
illumination models (such as Gouraud 
shading), where colors are only linear- 
ly interpolated across the face of a 
polygon. 

Dark maps are great because they 
allow gorgeous lighting effects without 
resorting to prelighting textures (which 
consumes gobs of memory) or an 
unwieldy surface cache architecture (a 
la the software-only version Of QUAKE). 
And because dark maps can be stored 
as monochrome textures of fairly 
coarse granularity, they can be modi- 
fied and downloaded quickly for 
dynamic lighting without interfering 
with the base textures. Thus, higher 
resolution base textures can stay resi- 
dent in texture RAM. 

COLORED DARK Maps USING RGB TEXTuRES. 
Dark maps are implemented using two- 
pass rendering; the first pass renders 
the dark maps, and the second pass 
renders the base textures. For colored 
lighting effects, you'll usually want to 
use RGB dark maps; during the second 
pass, the alpha blender is configured to 


LISTING 4. Direct3D version. 





multiply the fragment color with the 
existing color (Equation 5). The 
OpenGL form of Equation 5 is in 
Listing 3. The Direct3D form is in 
Listing 4. 

This blending mode assumes that 
your incoming dark texture map is in 
RGB format, or at least in a format such 
that the fetched texel will be converted 
to RGB before blending. For example, 
OpenGL supports two monochrome 
formats, GL_INTENSITY and GL_LUMINANCE, 
which should consume less memory 
than an RGB texture format because 
they support only gray scales. 
MONOCHROME DARK MApPs USING ALPHA 
Textures. Unfortunately, some of the 
poorer hardware accelerators out there 
don’t support “destination color” 
blending. They support only “source 
alpha” blending. When confronted 
with this sort of degenerate hardware, 
you can use an alpha-only texture and 
configure your blender such that you 
ignore the fragment color (source fac- 
tor is GL_ZERO or D3DBLEND_ZERO) and multi- 
ply the frame buffer contents by 
source alpha (destination factor is 
GL_SRCALPHA or D3DBLEND_SRCALPHA). Equation 
6 shows what this workaround looks 
like mathematically. 

Because an alpha-only texture pos- 
sesses no color content, you’re going to 
be stuck with monochromatic gray- 
scale shadows, albeit with the benefits 
of a reduced memory footprint and 
better support for hardware with limit- 
ed alpha-blending support. 

MIXING DARK MAPS AND VERTEX LIGHTING. At 
first glance, dark maps and vertex-ori- 
ented lighting — such as Gouraud 


LISTING 5. OpenGL version. 





glEnable( GL_BLEND ); 
glTexEnv( GL_REPLACE ); 
glBlendFunc( GL_DST_COLOR, GL_ZERO ); 





pDev->SetRenderState( D3DRENDERSTATE_ALPHABLENDENABLE, TRUE ); 
pDev->SetRenderState( D3DRENDERSTATE_SRCBLEND, D3DBLEND_DEST_COLOR ); 
pDev->SetRenderState( D3DRENDERSTATE_DESTBLEND, D3DBLEND_ZERO ); 
pDev->SetRenderState( D3DRENDERSTATE_TEXTUREMAPBLEND, D3DTBLEND_COPY ); 


EQUATION 5. Multiplying the fragment color by existing color. 





final.color = fragment.color * pixel.color + pixel.color *o 
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NG 5. Setting OpenGL texture 
ent to GL_ADD. 


glTexEnv( GL_ADD ) 


shading — seem mutually exclusive. 
This isn’t necessarily true. Vertex col- 
ors can be used for two powerful 
effects in conjunction with dark maps 
— dynamic lighting without dark map 
recomputation, and rendering colored 
dark maps even when those maps are 
monochromatic. 

Dark maps only modulate the color 
of the underlying texture. They are not 
capable of brightening a scene, only 
darkening portions of it. (This is why 
the term “dark map” is technically 
more accurate than “light map.” I’d use 
the term “shadow map,” but that’s 
already used to describe something else 
entirely.) For this reason, introducing 
dynamic lights to brighten a scene typi- 
cally requires recomputing the dark 
maps, a la GLQUAKE, which can be fair- 
ly expensive computationally and affect 
of texture download performance. 

However, vertex lighting can bright- 
en a scene using dark maps without 
imposing undue overhead, if you’re 
willing to accept the limitations of ver- 
tex lighting (these being a lack of per- 
spective correction and the need for 
heavy tessellation to render highlights 
well). Instead of rendering the dark 
maps using the API’s “replace/copy” 
texture environment, add the interpo- 
lated color to the dark map color. With 
OpenGL, this is accomplished by set- 
ting the texture environment to GL_ADD 
(Listing 5). Unfortunately, the GL_ADD 
texture environment isn’t a standard 
part of the OpenGL API; however, sev- 
eral OpenGL vendors are considering it 
as an extension. With Direct3D, you 
add the interpolated color to the dark 
map color by setting the texture blend 
mode to D3DTBLEND_ADD (Listing 6). Now, 


EQUATION 6. Destination color workaround. 





final.color = fragment.color * 0 + pixel.color* fragment.alpha 


LISTING 6. Setting Direct3D texture blen mode to D3DTBLEND_ADD. 





pDev->SetRenderState( D3DRENDERSTATE_TEXTUREBLEND, D3DTBLEND_ADD ) 


whenever a dark map is rendered, it 
will have the vertex colors added to it, 
allowing dark maps to be brightened. 
Earlier, | mentioned that one of the 
drawbacks of using an intensity or 
alpha format for dark maps is that this 
limits a game to using gray-scale dark 
maps. Once again, vertex lighting can 
solve this problem by rendering the 
dark maps using the API’s modulate 
texture environment, multiplying the 
color of the dark map with the color 
values interpolated from the vertices. 
These vertex colors will likely be pre- 
computed at the same time the dark 
maps are generated (probably by using 
some external tool). With OpenGL, the 
texture environment must be set to 
GL_MODULATE; with Direct3D, the texture 
blend mode must be set to D3DTBLEND_MOD- 
ULATE. These two techniques are mutual- 
ly exclusive on a single pass, because 
they both need control of the texture 
environment and vertex colors. 
DYNAMIC LIGHTING WITHOUT USING VERTEX 
COLORS OR RECOMPUTING DARK Maps. It 
would be nice if there was some way to 
dynamically light a scene without 
using vertex lighting or recomputing 
dark maps. And believe it or not, such a 
technique actually exists, although it 
requires a third pass — bear with me, 
it’s not as bad as it sounds (usually). 
The basic technique is simple — render 
your dark maps normally as part of 
your first pass. Now it gets tricky; on 
the second pass, render those parts of 
the scenes affected by dynamic lights, 


EQUATION 7. Configuring alpha blender for dynamic lighting. 


final.color = fragment.color * 1+ pixel.color *1 





LISTING 7. OpenGL version. 


glBlendFunc( GL_ONE, GL_ONE ); 
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Leo? 





LISTING 8. Direct3D version. 


and add the dynamic lights into the 
frame buffer. How you render the 
dynamic lights is up to you, because 
there are quite a few ways of doing this 
(heavily tessellated Gouraud shaded 
polygons, using “brightening” texture 
maps, and so on). Your alpha blender 
needs to be configured as in Equation 
7, [he OpenGL code is in Listing 7. The 
Direct3D version is in Listing 8. 

This will brighten the dark maps 
without recomputing or redownload- 
ing new dark maps, and also without 
using vertex lighting. The final pass is 
rendered using the standard multi- 
plicative dark map blending mode. 

The “brightening” phase can be con- 
sidered a “half pass,” occuring between 
the dark map and texturing passes. The 
sole purpose of this pass is to brighten 
up those regions of the scene specifical- 
ly affected by dynamic lights. If the 
portion of the scene being illuminated 
by dynamic lights isn’t very large, then 
the performance hit for this partial 
pass may not overwhleming, and may 
actually be less than the hit taken for 
recomputing and redownloading dark 
maps. 

In the future, both OpenGL and 
Direct3D will provide multitexture 
extensions. Multitexture extensions 
will allow developers to specify multi- 
ple textures per face and multiple tex- 
ture coordinates per vertex and to dic- 
tate how the multiple textures 
combine. Thus, a combined dark 
map/texture map can be rendered in a 
single pass by the application (even 
though an underlying API or driver 
implementation may render it in two 
or more passes). Such extensions will 
allow hardware to implement dark 
maps and related effects without 


pDev->SetRenderState( D3DRENDERSTATE_SRCBLEND, D3DBLEND_ONE ); 
pDev->SetRenderState( D3DRENDERSTATE_DESTBLEND, D3DBLEND_ONE ); 


http://www.gdmag.com 


Develop your gameplay, ea NETIMMERSE 
oS a t y W g mea : g iC _ automatically scales the visual realism 
.. no _ Our am e en ‘ ne. of your 3D scene based onthe 
a. — oe - computer's resources: from standard 

PC’s to MMX to 3D graphics hardware 

with Direct3D, OpenGL or our 


proprietary software renderer. 


NETIMMERSE 


ai) inlonle4-s-ee mal -eae) a @mtcelelmm-le)e)iler-balele 
must do by culling out polygons not 
directly seen by the player: Visual 
Occlusion Culling, LOD, BSP’s, 
portals...So your game looks better 


and runs faster than your competition. 


Get your title in 
stores before your competition with 
the features and tools you need: 3D 


Spatialized Sound, Collision Detection, 


» ss Video Textures, Behavior, Optional 
_ Terrain Rendering Module, Imports 


cc 3DStudio™, OpenFlight™, VRML. 


FULL SOURCE CODE, NO ROYALTIES 





“ MagBall® arcade game by GreyStone Defend3D: Free demo game Ofmorphing) §§—CsCV: Realtime Snapshot from “iF-22 Raptor — 
~~ by Interactive Magic: 80,000 sq. miles of 
<s... morphing terrain using NDL technology. 

SS 


Technology, early adopter of terrain technology from NDL website, 
NETIMMERSE technology. — 


rye Le 





_all tessellation done in realtime. 





ee 





C+*’Game Engifté 


for creating Scale-able 3D PC Content 


www.ndi.com sales@ndi.com 
West Coast +1 (415) 328-4388 East Coast +1 (919) 929-2917 


Canyon Runner image courtesy of GreyStone Technology. ©1997 NUMERICAL DESIGN LTD 











LISTING 9. Specular highlights with 
OpenGL. 


glTexEnv( GL_MODULATE ); 


requiring multiple passes, potentially 
improving performance dramatically. 
TWO-PASS SPECULAR LIGHTING. Another great 
use of multipass rendering is to inte- 
grate specular lighting into your tex- 
ture-mapped scene. Specular lighting is 
the additional lighting component that 
results from the reflection of light 
directly back to the viewer. Specular 
lighting is an additive component in 
most lighting equations and thus can 
saturate colors, unlike pure diffuse light- 
ing, which only modulates colors. 

With Direct3D, the specular color is 
iterated separately and is specified in 
the D3D(T)LVERTEX: : specular member. In 
theory, you can have specularly lit (at 


A scene from QUAKE with dark maps 
applied. 





the vertices) textures in a single pass, 
assuming that the driver has imple- 
mented this feature. With OpenGL, all 
lighting is evaluated into a single “dif- 
fuse/specular” vertex color, so if you 
wish to add specular lighting to a dif- 
fuse-lit textured scene, you'll have to 
use a second pass. Extensions to 
OpenGL are being proposed to address 
this deficit. 

To generate specular highlights with 
Direct3D (when there is no support for 
specular lighting) or OpenGL, you ren- 
der the scene normally on the first 
pass: that is, with diffuse-lit textures. 
The OpenGL code is in Listing 9. The 
Direct3D version is in Listing 10. 

During the second pass, the scene is 
rendered sans texturing, with specular 
lighting enabled (you don’t want to 
reapply the diffuse lighting) and Z- 
buffer writes disabled (this isn’t 
absolutely necessary, but is probably a 
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LISTING 10. Specular highlights with Direct3D. 


LISTING 11. OpenGL “night vision” 


effect. 


glEnable( GL_BLEND ); 

glBlendFunc( GL_DST_COLOR, GL_ZERO ); 
// set vertex colors to (0.0F,1.0F,0.0F) 
// and draw a screen size triangle 


performance win on a lot of accelera- 
tors). You then configure the alpha 
blender for additive blending using the 
same method described for the “two- 
and-a-half pass” light-map updates. 

The second pass will add specular 
highlights at vertices to the scene. To 
improve performance, an application 
should render only those portions of 
the scene that have specular highlights. 
FAKING OLD-FASHIONED PALETTE EFFECTS. | feel 
obligated to mention this, even though 
I hate it. Back in the Good Old Days of 
VGA, you could do a lot of neat tricks 
with palette manipulation. But the 
move to true RGB has forced a lot of 
programmers to reevaluate some of 
these hacks. Two of the more common 
effects that programmers used palette 
tricks for were full-screen color fades (for 
example, firing the fusion cannon in 
Parallax Software’s DESCENT) and night- 
vision effects (everything is green). 

Alpha blending can sort of emulate 
these tricks by rendering an screen-sized 
alpha blended polygon after you’ve ren- 
dered the rest of the scene. All together 
now...eeeewwwwww. Yes, it’s horrible. 
The obvious reason that I hate this hack 
is that you eat an entire level of depth 
complexity (and suffer the associated 
performance hit) for no other reason 
than to fake some cheesy effect. 

For a full-on fade to some color a la 
the DESCENT fusion cannon, a huge 
translucent polygon works fine — vary 
the alpha value over time to fade from 
transparent to full opaque. It would be 
nice to figure out a way to use fog for 
this effect instead, but both OpenGL 
and Direct3D have pretty limited fog- 
ging mechanisms for accomplishing 
this type of effect. 

For the night-vision effect, a huge 
polygon that acts as a green filter 
(attenuate out red and blue, pass green 
through unchanged) works adequately 


pDev->SetRenderState( D3DRENDERSTATE_TEXTUREMAPBLEND, D3DTBLEND_MODULATE) 








to fake the effect (note that real night- 
vision systems are absolutely nothing 
like this). The OpenGL code is in 
Listing 11. (Technically, you could 
accomplish the same effect with 
OpenGL by enabling only writes to the 
green channel using glColorMask, but 
that’s a pretty limited technique, and 
it’s not available under Direct3D). 

Remember, these are hacks, pure and 
simple, and not meant to be cutting- 
edge programming techniques. If 
someone out there comes up with bet- 
ter techniques for achieving these 
effects, please write me and I'll pass it 
along. In a forthcoming column, I’ll 
talk about some ways to achieve these 
affects using hacks that don’t rely on 
alpha blending. 


Performance Implications 


A’ application that uses multipass 
rendering will be stressing the tri- 


angle throughput and fill-rate capabili- 
ties of the API and hardware, assuming 
that each pass completely rerenders the 
entire scene. Not much can be done 
about the fill-rate hit, but an applica- 
tion can try to minimize the transfor- 
mation overhead if it’s willing to do all 
the transformations itself and use the 
API only for rasterization. 

If this is the case, a game can trans- 
form, project, and clip the scene once, 
but at each triangle render it twice (for 
example, once with a dark map and 
then with the base texture). This 
approach will reduce the amount of 
transformations performed, but at the 
cost of eating a state change at each tri- 


The same QUAKE scene in “fullbright” 
mode, with no dark maps applied. 
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angle (blending mode, blending func- 
tion, and current texture map values 
will be changed at least twice per trian- 
gle). With some hardware, these state 
changes can be so costly that it actually 
makes sense to just retransform the 
whole scene so that changes to the 
State are minimized as much as possi- 
ble. Alternatively, an application can 
cache the transformed vertex data and 
attempt to render triangles by material 
order, but the cache effects of this may 
be pretty grim. 

As I stated earlier, at this time nei- 
ther OpenGL nor Direct3D support 
rendering triangles with multiple 
simultaneous textures. However, such 
enhancements are likely in the future, 
making much of this maneuvering 
moot — you simply select the texture 
map, dark map, and a “mixing” func- 
tion for each triangle, and hopefully, 
the API and/or driver will just do the 
right thing. 

Another — hopefully short-lived — 
performance drawback of multipass 
rendering is that enabling alpha blend- 
ing can introduce a performance penal- 
ty on many hardware architectures 
(due to the overhead of reading from 
the frame buffer). The effect of this per- 
formance hit can be negligible to cata- 
strophic, depending on the hardware 
accelerator. 





Quality Implications 

nother drawback to multipass ren- 

dering is the limited precision of a 
typical frame buffer. When you're using 
a 16-bit display and rendering to it 
many times, you will suffer a loss of pre- 
cision due to quantization error. This 
error will manifest itself as visible band- 
ing when too many passes are rendered. 

No clear solution to these artifacts 

exists, aside from increasing the resolu- 
tion of the frame buffer. A 24-bit frame 
buffer is far less susceptible to multi- 
pass banding than a 16-bit frame 
buffer, but it may be a while before we 
see 24-bit frame buffers in widespread 
use for games. 


Caveats 

CO! course, nothing’s ever quite as 
simple as we’d like, so I'll talk 

briefly about some of the pitfalls you 

may encounter when integrating mul- 

tipass rendering into your game. 
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ORDER OF OPERATIONS. With multipass 
rendering it’s possible to go absolutely 
crazy and render a scene using a com- 
bination of just about every effect 
imaginable, with the caveat that per- 
formance will likely suffer if you go 
overboard. I’ve presented a mixed bag 
of techniques that can be combined in 
many different ways; always keep in 
mind your desired order of operations! 
When mucking about with texture 
environments, alpha-blending modes, 
and multiple passes, it’s easy to acci- 
dentally render things out of order, 
particularly when dark maps are 
involved. For clarity, you should write 
down exactly what you're trying to 
accomplish, then go through your 
passes and make sure that what you’re 
getting is what you want. 

Z-BUFFERING. Keep in mind that if you’re 
Z-buffering, you must use the “less or 
equal” (GL_LEQUAL or D3DCMP_LESSEQUAL) com- 
parison function for the second pass to 
appear. This mistake is easy to make, 
since programmers often will use 
GL_LESS or D3DCMP_LESS by default. 
COMPATIBILITY. When it comes to com- 
patibility, alpha blending suffers 
from one big drawback — only a 
handful of current accelerators sup- 
port full alpha blending. Vendors had 
many understandable reasons to 
ditch alpha blending in early hard- 
ware designs, including cost, perfor- 
mance, and lack of encouragement 
from software developers. My theory 
is that alpha blending didn’t become 
a priority until some weenie product 
manager needed to fill in one more 
bullet item for a presentation and 
randomly selected a feature from a 
graphics textbook... but that’s just 
me being optimistic (as if product 
managers own graphics textbooks). 
To make matters worse, Microsoft’s 
Direct3D team placed a strong 
emphasis on chromakey and stippled 
transparency instead of true alpha 
blending (as a matter of fact, alpha 
blending was/is simply broken in 
Direct3D Retained Mode), mostly 
because they were obsessed with soft- 
ware rendering performance and did- 
n't seem to understand that alpha 
blending served a larger purpose than 
just translucency. 

For these reasons, there is a large 
installed base of accelerators that don’t 
support alpha blending. If you want to 
be bold and say that this sizable group 


of useless accelerators is irrelevant, go 
for it and surf the cutting edge. For 
those of you targeting every accelerator 
in existence, you may not want to 
emphasize alpha blending too much 
because of its current lack of support. 
I'm fairly certain that all the next gen- 
eration of accelerators (early to mid 
1998) will have support for alpha 
blending — those that don’t, well, you 
can just assume they aren’t going to 
matter. 

If you want to mess around with this 
stuff today, I’d recommend that you 
pick up either a Rendftion Verite ora 
3Dfx Interactive Voodoo accelerator (or 
both, since they can coexist in a sys- 
tem); these two chipsets seem to imple- 
ment the most important alpha blend- 
ing capabilities correctly. Hopefully, by 
the time this article isn your hands, 
some newer hardware from other man- 
ufacturers will be shipping with com- 
prehensive alpha-blending support. 
Foc. One downside to multipass render- 
ing is that fog doesn’t “just work,” at 
least not with OpenGL. OpenGL speci- 
fies that fogging occurs before alpha 
blending, which makes multipass ren- 
dering with fog significantly more 
complicated than it could be. There are 
ways around this, and in a future col- 
umn, I plan on going over some of the 
subtleties of fogging with multipass 
rendering. 

With Direct3D, fogging is even worse 
— it may or may not be broken, 
depending on how a particular hard- 
ware implementation is done. My best 
advice is to avoid using fog with multi- 
pass rendering with Direct3D — it’s 
tough enough getting basic output 
from Direct3D — trying to do multi- 
pass with fog with Direct3D is just beg- 
ging for trouble. 

I'd like to thank Michael Gold and Gary 
Tarolli for reviewing this month’s column. 

Brian Hook is a poser who somehow 
managed to land a job at id software. 
When he’s not coding or playing with his 
dog he manages to write the occasional 
column for Game Developer. 


FOR FURTHER INFO 
An excellent reference on the subject of 
using texture maps for shadows and 
lighting effects is Fast Shadows and 
Lighting Effects using Texture Mapping 
by Segal, Korobkin, van Widenfelt, 
Foran, and Haeberli (SIGGRAPH ’92). 
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by Dave Sieka 





Take Me Into the Ball Game 





t’s about providing experiences. One of the enduring attractions of computer 
games is their ability to take us to fantastic places and immerse us in adventures 
far outside the realm of our daily existence. How else could you hope to get up- 


close and personal with the Orcs of Azeroth, the battlemechs of clan Jade Falcon, 


or... the Green Monster of Fenway? That’s right: Game artists know that it’s plenty tough 


to concoct a fantasy or sci-fi milieu from scratch, but a very different set of challenges 


awaits those daring or foolhardy enough 
to recreate recognizable real-world set- 
tings for their players’ enjoyment. 

Sure, it may sound easier at first, and 
in some ways it is. The convenient 
thing about the real world is, it exists. 
The artist doesn’t have to make it up. 
But there’s a dark flip-side to that coin. 

“The problem with a recognizable 
locations and characters,” admits 
Andrew Johnston of Wizbang! Software 
Productions, “is that people know exact- 
ly what they are looking at and can 
quickly discern any differences between 
the game and the real world.” Johnston 
is programming lead and project man- 
ager at Wizbang! on the MICROSOFT 
BASEBALL 3D project. The ambitious goal 
of this game-in-progress (due in stores 
November 1997) is not just to create an 
entertaining 3D baseball game, but to 
give fans of the national pastime the 
opportunity to go to bat as their favorite 
slugger in the hallowed arena of their 
hometown stadium, to play on big- 
league ballfields we mortals only get to 
see from the stands or on TV, and to rub 
elbows with recognizable hardball 
heroes. Moreover, the objective is to 
provide this experience in a more con- 
vincing manner than has been accom- 
plished by previous baseball games: 
with ballplayers, fans will recognize 
without having to see a name in the 
corner of the screen and with authenti- 
cally detailed ballparks, not to mention 
a real-world physics model, ambient 16- 
bit sound, and force-feedback joystick 
control that lets you feel the ball con- 
necting with your virtual bat and the 
difference between running on outfield 
grass or baseline dirt. A look at what 
Microsoft and Whizbang! have gotten 
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themselves into can be eye-opening for 
artists and game developers who expend 
their creative efforts bringing players 
face-to-face with creatures that never 
lived in settings that don’t exist. 


In the Ballpark 

hough Wizbang! is developing the 

game, the challenge of capturing 
the essence of Major League Baseball 
began at the Microsoft Games Group, 
where most of the content — such as 
3D models and textures — is created. 
Microsoft began by contracting with 
model-making mercenaries 3Name3D 
to create most of the prototype models 
for the 28 Major League Baseball stadi- 


Detailed face and uniform textures help 
give each 1,000 polygon player model 
an identity, which baseball fans will be 
able to recognize on sight. 





A real-world environment and characters may 
sound easier than concocting a fantasy world 
from the ground up, but listen to what hap- 
pens when you set out to create the most 
realistic 3D baseball game yet. 


ums. The first park — Baltimore’s Oriole 
Park at Camden Yards — came in at 
about 28,000 polygons. Before the 
model’s delivery, however, the polygon 
budget had been drastically reduced. 
Artists at Microsoft went to work trying 
to make the model compatible with the 
hardware-accelerated target user system 
and with their game engine, Wizbang!’s 
ADLIB (Authoring and Design 
Language for Interactive Behaviors). 
(See Game Developer, August/September 
1996, “Bringing Life to Hyperblade” for 
more information on ADLIB.) 


At this stage in the project, the 3D 
accelerator boards Microsoft was devel- 
oping for were still in the beta stage of 
development themselves. Given the 
inchoate nature of the target hardware, 
determining accurate budgets for poly- 
gons and texture maps was difficult. Jim 
Millar, 3D art coordinator at Microsoft, 
described the process as “trial and error, 
with a bit of guessing thrown in.” 

“We wanted authenticity with each 
stadium,” asserts Tracy Curtis, who 
worked with Millar to recreate the 
Camden Yards model to fit within the 
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MICROSOFT BASEBALL 3D lets players go 
to bat as their favorite slugger in their 
hometown ballpark. 





parameters of the game engine and tar- 
get system. “We want the player to rec- 
ognize the stadium he or she has cho- 

| sen to play in.” 

Still, though BASEBALL 3D would be 
reliant on hardware acceleration and 
thus less constrained in terms of the 
amount of detail it could afford, a very 
real limit still had to be observed for sta- 
diums’ polygon count and texture mem- 
ory budget. The sought-after realism 
would have to come from ingenuity and 
finesse rather than brute-force accretion 
of detail. To complicate matters, the 
game features a player-controlled camera 
offering unlimited viewing angles, 
meaning that each stadium has to be 
fully realized. Everything that could be 
seen from the field would be seen. 

Armed with stadium blueprints, pho- 
tos, illustrations, and photographs of 
architectural models, Millar and Curtis 
diligently reworked the Camden Yards 
model an estimated 30 times before 
getting what they wanted. They had 
scaled the original 28,000 polygons 
down to only 850, with a texture mem- 
ory budget of 350 - 800K, depending 
on the user’s video board capabilities. 
With placeholder textures applied, the 
working stadium model could be hand- 
ed off to programmers while Millar and 
Curtis tackled several additional mod- 
els that had been built to the original 
high-resolution specifications. 

With most of the geometry problems 
resolved, Millar and Curtis turned to 
refining textures. Their goal was to com- 
pensate for the coarsening of detail that 
resulted from the simplified geometry 
and to capture the details that bring a 
stadium to life. In addition to official 
stadium reference materials, they looked 
elsewhere to get the details right. 

“We've gone outside (and discovered 
there is an outside to Microsoft!) and 
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taken pictures of grass and trees. We 
look at postcards of city skylines,” 
Millar explains. “We ask our friends 
around the country to take pictures of 
stadiums for us when they go to games. 
IT even had my grandmother-in-law, 
who’s a librarian in Baltimore, fax me a 
picture of the Baltimore city flag.” 

This attention to detail must span all 
28 Major League Baseball stadiums, 
including different textures for night 
games. Though many textures can be 
shared between ballparks, each park 
has at least as many custom textures as 
shared textures. The aim is to give each 
venue a Character all its own, recogniz- 
able by local fans and rivals alike. 

“Tf it isn’t close to the real thing, then 
the game wasn’t worth making,” Curtis 
explains of the effort. “There are some 
great baseball games that do have 
authentic stadiums, but lack the unique 
texture details our game provides.” 


Men in Uniform 


he real stars of the game, of course, 

whether onfield or onscreen, are 
the ballplayers. As much as detailed 
stadiums add to the game, it’s the 
fabled Boys of Summer who give it life, 
but only to the extent that artists and 
developers are able to capture the 
essence of that life. That objective suf- 
fered a hit early on, as the decision was 
made to keep the BASEBALL 3D ballplay- 
er model relatively low-resolution due 
to budget and time constraints. 

“The game is made to be scalable,” 
explains Wizbang!’s Andrew Johnston, 
“so that BASEBALL 3D will use all of the 
features that a high-end board sup- 
ports, while also running on low-end 
boards that may not support all fea- 
tures. On earlier projects, the costs of 
generating both low-polygon models 
for the software-rendered version of a 
game and high-polygon models for the 
hardware-accelerated version were pro- 
hibitive. In this case, the decision 
invariably was not to build the higher- 
detailed models, since low-polygon 
models could be used for all boards. 
This is a big disservice to those 3D 
accelerators that can handle much 
higher throughput rates.” 

“The challenge is making an organic 
form — the human figure — look real- 
istic when built out of flat, angular 
polygons,” points out Microsoft Games 
Group art director Mary Jo Kovarik. 


Although at 1,000 polygons, the “low- 
polygon” ballplayer model allows more 
detail than many figures in recent 3D 
games, it was a bit of a come-down 
from the original 2,000 polygon proto- 
type, described by modeler Randy 
Reeves as “quite dashing.” The tight 
polygon budget adds an extra chal- 
lenge to Microsoft’s effort to create rec- 
ognizable athletes, part of which 
involves matching models to motion- 
capture data. The upshot is that artists 
have had to work harder to breathe life 
into the still rather blocky 1,000 poly- 
gon model. Make that models: separate 
versions for fielders, batters, and catch- 
ers, aS Well as six increasingly lower- 
polygon LODs for each, the smallest of 
which allows only 28 polygons. 

“Great attention had to be paid to 
make the physique of the modeled 
character match up with the skeleton 
from the motion-capture session,” 
Kovarik explains. “Several revisions 
were necessary to get the model work- 
ing properly with the game engine.” 

“It has been quite a delicate balanc- 
ing act,” Reeves allows with stoic 
understatement, “keeping the polygon 
count within tolerance, keeping poly- 
gons planar, and still accept motion 
data, still have decent-looking players, 
still remain generic enough.” 

“Generic” because a single, all- 
encompassing body-type has been set- 
tled on. The initial plan was to have 
several body types to accommodate dif- 
ferent physiques: heavyset, tall, thin, 
and so on. Time — the enemy of all 
game developers — did away with that 
aspiration as well. 

Yet Microsoft’s artists and Wizbang!’s 
developers remain determined to cap- 
ture the identities and personalities of 
players. Multiple instances of the gener- 
ic model are created within the game 
for each of the players on the field. This 
allows each ballplayer to be individual- 
ly customized with the correct skin 
color, uniform, and jersey details. 
Further, a lot of polygons — 13% of the 
total — are used in the ballplayer 
model’s head to add realism. A range of 
detailed generic face textures provide 
even more character. Unique face tex- 
tures have been created to represent the 
most famous and recognizable big lea- 
guers on each team. “The realistic faces 
created by Microsoft texture mapper 
Rod Chang are one of the defining fea- 
tures of our model,” Kovarik boasts. 
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“It was challenging because people 
know what these ballplayers look like,” 
admits Chang. “It’s important that they 
recognize the players when they see 
them, not just by seeing their names on 
the screen.” Chang starts with photos of 
the players, arranging facial features to 
create textures to be applied to the 
model. Since the geometry is identical 
for each ballplayer, distinguishing fea- 
tures that might be structural — high 
cheek bones, a strong jaw line — can 
only be achieved by attention to the face 
texture. 

Chang is also in charge of creating 
texture maps for player uniforms. He 
started by bringing in a real uniform to 
observe exactly how it fits and creases. 
Noticing that pinstriped uniforms 
weren’t simply composed of vertical 
stripes — that pinstripes actually met in 
certain seams — he carefully arranged 
for the uniform textures to reflect this. 
More than just capturing photorealistic 
details, he strives for drama and verisi- 
militude by simulating how uniforms 
would look in the bright sunlight of 
summer afternoon, adding appropriate 
highlights and shadows to textures. 

Of creating all the necessary jersey 
details, Chang says, “We had to do it 
because it made the game look more 
realistic,” but admits it was the most 
tedious part of the job. Individual tex- 
ture maps had to be created to repre- 
sent names and numbers for each of 
three jerseys worn by 25 different 
ballplayers on all 28 big league teams. 
Modeler Randy Reeves fashioned a sep- 
arate torso for ballplayers with single- 
digit jersey numbers, as those textures 
required different placement. 


E-Motion 
f course, even with painstaking 
and skillful modeling and tex- 
ture-mapping, a 1,000 polygon human 
figure isn’t going to impress anybody 
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till it’s set convincingly in motion. 
BASEBALL 3D will make use of extensive 
motion-capture data to bring its 
ballplayers to life with around S00 
motion routines. Though I tend to give 
artists most of the credit for the visual 
success of a game, I’ve got to give a nod 
to techs John Pella, Microsoft’s motion 
capture technical director, and pro- 
grammer Stuart Rosen at Wizbang}, 
who are taking the use of motion-cap- 
ture animation to the next level. 

Two players from the Triple-A Tacoma 
Rainiers — Mike Knab and Sal Rosado — 
were brought in to Microsoft’s in-house 
motion capture facilities to “go through 
the motions.” Program manager and 
designer Rich Choi points out that par- 
ticular attention was paid to miscella- 
neous motions that really add character 
to the game. Though the axe of time may 
fall on some of this plethora of kinetic 
personality, Choi is looking at including 
15 batting stances (so you'll definitely see 
the difference between Jay Buhner’s low 
hand-open stance and Edgar Martinez’s 
high, looping stance), 36 swing motions 
(so a swing at an inside pitch looks differ- 
ent than a swing at an outside pitch, and 
so on), 4 pitching motions, 6 home-run 
trots, 4 running speeds, and numerous 
catch-and-throw motions such as 
thrown-from-knees (Caminiti-style), 
glove-toss, spitting on the ump (well, 
maybe not), and so on. 

Using proprietary software, John 
Pella’s motion-capture lab at Microsoft 
processes, optimizes, blends, mirrors, 
and loops all this data. This makes it 
possible for programmers to easily blend 
or interpolate among a library of cap- 
tured motions. Softimage is used for 
editing and additional keyframing, but 
hand-editing is kept to a minimum by 
implementation of programmatic solu- 
tions wherever possible. “Writing a filter 
that performs some editing task on a 
huge batch of motions not only saves an 
enormous amount of time,” Pella 
observes, “but it can be reused,” reduc- 
ing the cost and complexity of incorpo- 
rating motion capture on future projects. 

Motion-capture animations are inte- 
grated with player behaviors under 
Wizbang!’s ADLIB engine. Wizbang! 
programmer Stuart Rosen explains that, 
in object-oriented fashion, behaviors as 
well as geometry and texture-mapping 
characteristics are “owned” by the indi- 
vidual ballplayers. Rosen has developed 
a bipedal simulator as an extension of 


the ADLIB engine, which uses motion- 
capture animation data as a source for 
producing true bipedal motion for the 
ballplayer models. The result: Players 
actually walk and run rather than slide 
across the field surface, producing a 
much more realistic experience. 


Get Real 


H t’s the new breed of graphics acceler- 
ation boards that act as the opener 
for the whole “realism” can of worms. 
Hardware acceleration allows higher 
polygon throughput and higher tex- 
ture memory, which, at least in terms 
of system performance, enable artists 
to invest environments and characters 
with greater levels of detail. Microsoft 
texture artist Rod Chang puts it in per- 
spective: “Working with a game that 
didn’t require hardware-acceleration, 
the main objective of the artist was to 
make it as real as possible with the lim- 
ited texture budget. For Baseball 3D, 
the challenge is in finding enough time 
to create all the detail that could not 
have existed in previous games.” 

But as designer Rich Choi avers, 
hardware-accelerated 3D is the future, 
and before long all new 3D titles will 
require 3D acceleration. “It also makes 
our job much more interesting and 
challenging.” 

If you think opting for a real-world 
setting and characters is taking the easy 
way out, the response from the BASEBALL 
3D team would probably be “Get real!” 

This is Dave Sieks' last regularly sched- 
uled installment of The Artist's View, a 
column he has authored since 1994. He 
leaves the column to devote more time to 
outside projects — some of which have 
absolutely nothing to do with computer 
games, if you can believe such a thing — 
but will continue as a contributing editor 
to Game Developer. You can contact him 
via e-mail at dave@ward1.com. 


Be Se ae 
Force-feedback joystick control will let 
players feel the difference between run- 


ning on infield grass or baseline dirt. 
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I-FORCE is the latest gaming technology to take the computer industry by storm. When added to a 
joystick; steering wheel, or other gaming peripheral, -FORCE enables users to FEEL jolts, blasts, liquids, 
springs, textures, surfaces, and countless other realistic physical sensations. These are not simple bumps 
or vibrations - l-FORCE provides complex physical sensations that replicate gaming reality. 

I-FORCE is currently targeted at PC, Arcade, and Console platforms. 
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hings are pretty rosy for us game developers — a fairly healthy industry, 
super-casual work environments, and creative, exciting new technolo- 


gies to explore. But it’s not all fun and profit: We've got our problems, 


and there’s plenty of room for improvement. Aborted projects are a 
major source of burnout, generally cutting into the fun and glory 
detlarebintemecavalejeyestaelansecelel (em olen 

One of the hallmarks of failed projects is communication 
breakdown. Why? 

Because good communication is damned hard, and it’s one of 
those mushy personal skills to boot. It’s much easier to study tools 
than to learn to ask questions such as “how many textures can I 
use?” 

This article teaches both skills to artists. Once we identify the 
artist’s coworkers,we’ll examine the psychology of the artist/pro- 

Ae Vesb eto m cathe lo enyeniommelieclingmer-telelete)(ehpm-talemusleniomsetauie-le) (a 
nuggets of advice. 

A word of warning: I’ve sketched some big stereotypes in this arti- 
cle: They’re not intended to be rude or to offend — I wrote them to 
help identify common interaction problems. So grit your teeth and 
hold your fire if you’re insulted by the idea of stereotyping, but do 

_Speak up if you disagree with my basic generalizations. I write from 
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a wide and varied experience, but it’s 
only one person’s experience — 
more is always better. 


Example Artist Interaction: Q&A for 
New RI3D Art Assignment 


efore starting a new assignment, 

dolor Dushimpeliaen mow cole imnjecetile 
rbabce)ueet-teloveu-loleleimeetom one) (eam suet 
out proper briefing, the art isn’t 
reXo)bakem Come eat-in omuelcmelcen we) maele 


game. This major communication 
event provides a rich stew of interac- 
tions to observe. Since art assign- 
ments are very project-dependent, 
no complete, general-purpose check- 
list for eliciting the proper informa- 
tion has yet been developed. 
Nonetheless, I’ve created a hypothet- 
ical conversation so we have realistic 
information. 

DoW cehvanieser-bulepmeslamo.qolau(aelaae 
eroyelau.(clmr-Daen ims er- Km lenim@olaaemellucemne 
create artwork for a real-time 3D 


game already in development. The 
artist is now getting acquainted 
with the project and its team mem- 
bers. As the artist asks questions of 
various team members (in the left- 
ok-bote mee) tepeebeny pm mr-ber-UbwAcmaela 
answers from both a psychological 
(“psych”) and a technical (“tech”) 
Ciecbelel olevbelemyveuleemeleme-vem acm ial 
the right-hand columns. This will 
help you understand the context of 
PVelemoslelears. lacey en mola eubevemael= 
answers. 


Artist: 


Producer: 


3D comic strip about a cat that is 


hunting a bird, as the bird sits in 


What’s the basic idea of the game? 


We’re building a simple, real-time 


Psychchological 
Interpretation: 
Contractors are often 
brought into a project 
without being told any 
more than necessary. 
The artist needs to know 
some basic context to 
do his or her job. 


its cage. The style is simple with 


somewhat realistic rendering. It’s a 


cartoon, but we don’t want any 






exactly? 


Designer: 


animations. 


Programmer: 
polygons. 
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drastic squash and stretch effects. 


What artwork do you need, 


A bird, a cat, the birdcage, 


What’s the face/polygon (or 
vert) budget? 
For the cat, the budget is 250 


Technical 
Interpretation: The 
purpose of this ques- 
tion is to clearly define 
the assignment. If the 
artist had more design 
freedom, he or she 
would make a detailed 
list of objects to build. 
Psych: This answer is 
quite brief, possibly 
because the designer 
hasn’t thought out the 
scene in much detail. 
Also, this designer 


and the room, plus some 


bilities. 





doesn’t want to com- 
mit to a list, in case 
something else 
comes up later. 
However, the artist 
should continue to 
find out as many 
specifics as possible: 
What kind of anima- 
tions are needed? 
What’s in the room? 
These details will def- 
initely affect the 
scheduling. Also, this 
is a good time for the 
artist to vaguely 
describe the planned 
style (quick exam- 
ples) to make certain 
that the designer 
likes it. This kind of 
early communication 
can r prevent dis- 
agreements about 
style. 


Tech: The basic geometry budget must be known up front 
before any work begins. Like most budgets, the polygon 
count is usually approximate, since its purpose is to guar- 
antee a certain frame rate for the final game. A cat can be 
created using 250 polygons, but it won’t be very detailed, 
so let’s hope the engine has good texture-mapping capa- 


Psych: This is another question that can make the artist 


feel trapped, because it’s where the rubber meets the road. 
Often, programmers don’t know the polygon budget or 


make up untested numbers. This uncertainty could be the 


sign of a basic design problem (which means it could be a 
sensitive issue). Experienced artists will gently explore the 
“why” of this budget and see if it matches their intuition. 
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Need the Right Tools for Realtime 3D? 

GameGen II was specifically conceived and designed for building 
fantastic realtime 3D game worlds for your target hardware. 
GameGen II is packed with the kind of power tools you need to meet 
tough time-to-market schedules. GameGen II puts the right tools for 
realtime in the hands of your artists. And, MultiGen's OpenFlight™ 
data format will help your programmers put peak realtime 3D 
performance in your game. 


Need More Proof? Check out these hit titles built with MultiGen tools: 


On PC - Twisted Metal 2”, Jet Moto”, Death Drone™ Cyberia™2 

On Sony® Playstation" - Warhawk, Twisted Metal™ 

On Nintendo 64° - Super Mario 64", Super Mario Kart 64", Wave Racer 64™ 
In the Arcade - San Francisco RUSH™ 

In LBE's - Disney's Aladdin” VR Adventure, Magic Edge™ 


MultiGen and Industry 
aresent the Total Solution 


ww.multigen.com 
(408) 261-4100. 


THE REALTIME 3D COMPANY 


Phone: 408 261 4100 
email: sales@multigen.com 
www.multigen.com 


NOW HIRING TALENTED PEOPLE. 


Email your resumé to: jobs@multigen.com 





Op enGVS, SDix Glide Support y ~ 
® * | 
just add water 


game runs NATIVE on consumer and professional level 3D 
graphics accelerators based on Voodoo Graphics™ and 
\. Voodoo Rush™ including... 





° Quantum3D’s Obsidian™ and Ventana™ 
e Diamond’s Monster 3D 
° Orchid’s Righteous 3D 










*.. well almost. . . fo get realtime, | ; is ¢ Deltron’s Flash 3D 

graphics hardware accelerated 3D OpenGL™ Support \ ¢ Hercules’ Stingray!28/3D 

games, you may need to add a dash ) eee ee 

of programming, a pinch of 3D OpenGVS supports OpenGL™ -- 50 your game also runs on 
workstations and high-end 3D accelerators that your 


models, a little audio, some network- \ | ce . 
\ developers and artists use for content creation, including... 


ing and textures to taste. But in any 





case, you can save months of devel- | * Silicon Graphics IRIS ¢ Real3D Pro 1000 and 100 | 

se e DEC workstations with e Intergraph IntenseSD, Z| 
opment time, without sacrificing : 

' FowerStorm Graphics and V 
framerate performance, by using ¢ Sun SPARCStations ¢ E&S/Mitsubishi SDPro 
OpenGVS as the realtime 3D scene e DDLabs GLint and based 3D accelerators 
manager for your upcoming graphics Fermedia based OpenGL e Hitachi Spherix 
accelerators ..to name a few. 


hardware accelerated game. 


Mango Grits did — and it’s enabled 
them to develop their award-winning 
3D coin-op, LBE and consumer PC 
game in record time. Why? 
Because OpenGVS provides all of 
the realtime scene management 
features, including all of the hard 
stuff like object level of detail, 
dynamic texture paging, object 
culling, 3D-OOP, collision detection, 
LOD and texture management, 
visibility culling and damn _ near 
everything else you need to take 
advantage of today’s hot new PC 
graphics accelerators. 


Stop by the Quantum3D booth at 
SIGGRAPH ‘97 (booth no. 2057) 
and register to win a Quantum3D 
Evaluation Kit ($2,500 Value). | 
While you're there take a ride on 
the Mango Grits/Jessler LBE motion 
seat or visit their web site at 
www.mangogrits.com and see what 
OpenGVS can cook up for you. 














For more information, check out — 
httpo://www.gemtech.com or call us _ 
at (714) 598-0961; FAX (714) 598- 
0966. Also you can send email to 
into@gemtech.com. 


Tech: The usual answer to this simple question is 
either “Only tris [three-sided polygons] are sup- 
ported,” “Quads [four-sided polygons] and tris are 
supported,” or “Convex planar polygons with any 
number of sides are supported.” When tris are 
used, geometry doesn’t have to be planar and 
Artist: What kind of polygons are supported? convex. This type of geometry is easier for the 






artist to work with, but requires more tris to build 
a model. Quads and n-sided polygons must be pla- 
nar and convex, but fewer polygons are necessary 
to construct planar objects. 


Programmer: 










Convex planar polys are supported. 


ical programmer’s solution isn’t the 
only way to merge tris into poly- 
gons. For instance, sometimes a part 
of the art import procedure accepts 
a 3D data file, looks for coplanar tris 
that share edges, and replaces them 


Tech: This is a pretty stan- 
dard solution to the prob- 
lem that some modeling 


How are the polygons tools have, most notably 


created from tris? 3D Studio MAX and 3D 
Studio 4.0. The problem is WaT Poly EONS. 
Programmer: If two tris share an that the tools don’t direct- 
ly support any polygons 


invisible edge, they will Tech: This question 
applies if the import pro- 
cedure has the ability to 
FIGURE 1. T-sections. accept slightly noncopla- 


nar quads as coplanar. 


i? This can save a lot of 
unnecessary editing, since 
Vert 4 it’s common during nor- 
" mal construction for some 
faces to be slightly non- 
coplanar; it’s difficult to 
make all faces perfectly 
Vert 3 


coplanar. 


besides tris. Our hypothet- 
be merged to a quad. 





What tolerance, if any, is 


used when deciding that a 


Tech: The most difficult aspect of this 


. , ? 
quad saci planar: question is agreeing on what a T-intersec- 









Programmer: One degree or less out of tion is. As Figure 1 shows, T-intersections 
occur when one face touches another face, 
plane is O.K. either in the center or at an edge, without 


sharing all vertices. 
If the answer is “no,” the artist needs to 
understand the consequences because some- 
times T intersections are almost impossible to 


Artist: 







Are T-intersections allowed? 










prevent. 
Programmer: Yes. 
on intersections. Be sure 
that the programmer 
agrees on the definition of 
Tech: This question may “intersecting faces.” What 
be asked instead of the artists generally need to 
sorting question that fol- know is whether two faces 
Artist: Are intersecting faces allowed? lows, but an understand- can cross each other, 
Programmer: Vac ing Of ae eb Ses sorting pps a ses - a plane 
options is preferable to a if they are coplanar) of 
simple yes or no answer intersection. 
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Degrees of Separation 


emember the movie 
Six Degrees of 
Separation? It was a 
heartwarming story 
about some poor guy who 
scammed his way into high soci- 
ety, with the shocking conclusion 





that poor people are human after all. the specific game experience. 
Anyway, the title expresses an intense e Producer. Generally, the person in 
idea: Everyone is a friend of a friend of a charge. The producer makes decisions 
friend of a friend of a friend of a friend about what the game will and won’t 
(hence the term “six degrees”). consist of, in terms of its features and 
Let’s apply this idea to the artist hard the overall look and feel. They also 
at work on a game. The artist’s first- coordinate other development 
degree contacts are the developers that efforts, such as sound and testing, 
the artist interacts with daily, as shown and act as a firewall for publishers, 
in Figure 2; second-degree contacts per- lawyers, press, and other nondevelop- 
form functions such as testing and ers involved in the project. 
sound production, as well as nondevel- e Lead Game Programmer. This per- 
opment things such as legal, marketing, son decides what the game can do 
and so on. (and codes the functionality of the 
e The Art Director. This person tells game). Depending on the team, the 
the artist what design/style of art to lead programmer may or may not 
create and reviews the work for visual directly interact with the artist. 
quality. ¢ Project Manager. The project manag- 
¢ Artists. Peers who interact as they er keeps track of the schedule, equip- 
work. Other artists who may be work- ment, and costs. Sometimes, the pro- 
ing off site report directly to the art ducer takes on this role. 
director. 


¢ Tool Programmer. This person tells 
the artist exactly how to import art 
into the game (and usually writes 
that code). 

¢ Game Designers. The designer 
decides what art pieces are needed for 


Commercial 
artists have 
been trained 

to impress 
their audience, 
not their peers. 


FIGURE 2. The artist’s first degree contacts. 





GAME DEVELOPER AUGUST 1997 http://www.gdmag.com 










Artist: 


Programmer: 


Artist: 


Programmer: 





Artist: 


Designer: 
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What kind of sorting is used? Per-pixel 
Z-buffer? Per-face BSP-tree sorting? 


Z-buffer sorting, with object culling. 


Are there any special shapes that should not be 


No line-face, point-face, or 1,000:1 skinny faces. 


Tech: This question 
reflects the fact that 
some graphics engines 
don’t cope with strange 
faces, such as a “line- 
face,” which only uses 
two vertices, or a “point- 
face,” which only uses 
one vertex. Also, some 
engines don’t handle 
long, thin faces well 
(such as a triangle that 
fits in a 1,000x1 rectan- 
gle). Asking this ques- 
tion should reveal all 
those special cases, if 
there are any. 


How will the models be seen? 
What viewpoints does the player 


use during the course of the game? 


The camera will orbit the cat, bare- 


ly within the room. The cat will 
rarely take more than 25% of the 
screen width, and usually only 
10% or so. We won’t see the cat’s 
underside very often — the view 
will be mainly from a six-foot-tall 
person's standpoint, much as 
you'd see a real cat in a living 


room. 


Tech: The main purpose of this 
question is to determine whether 


intersecting faces are supported 


(Z-buffering allows intersecting 
faces, but most other sorting 
methods do not), but the 
answer can affect other areas 


as well. 


Psych: This is probably 
the hardest question to 
which to get a straight 
answer. Of course, 
RT3D means the view- 
point usually isn’t 
defined, and the design- 
er can’t know the view- 
ing positions. The good 
news is that artists only 
need to know very gen- 
eral information: what 
parts will be scruti- 
nized, and which are 
rarely seen. Ideally, 
they will know more: 
how and where the 
object will be in the 
scene, what the mini- 
mum, maximum, and 
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typical viewing 
distance will be, 
and what the 
field of view is. 
Tech: With 
enough informa- 
tion, the optimal 
size for an object 
is a known quan- 
tity. In this 
example, multi- 
ply the screen 
width (640) by 
the cat’s length 
onscreen (25%) 
to conclude that 
the cat’s optimal 
size is about 160 
pixels long. This 
number is useful 
when choosing 
texture sizes 
(128x128 for the 
foot is way too 
detailed) and 
geometry detail. 






































DEVELOPER 





TEAM BUILDING 





Artist: What kind of animation will this 


Tech: The most common types of real- 
time animation include hierarchy, ani- 
mated bitmaps, 3D morphing, or “none 
3D morphing with support for bones. at all.” This question will probably elicit 
a lot of detailed discussion on how to 
build the animation. Once the anima- 
tion type has been settled, it’s a good 
idea to build a simple test case and 
make sur.e it works. 

Psych: In our example, we're getting a 
pretty sophisticated real-time animation 
system. That probably explains the low 
face budget — fancy animation meth- 
ods usually hurt performance. It might 


How do I get animation be a good idea to verify this theory with 
the programmer. 


model be able to use? 






Programmer: 


data into the engine? 





Programmer: 3DS morph animation data 


is directly supported, so 


Tech: This critical question tells the artist exactly 


simply save the morphin 
ey 6 & how to import animation data — it’s usually much 


animation sequence with harder than importing the geometry and textures. 
For example, sometimes the artist must supply a 
the file name of the action string of 3D models as keyframes (STALKO1.3DS, 





_ STALK.3DS, i a eae ee STALKO3.3DS), or sey. a 

ported directly out of the 3D Studio animation 
POUNCE.3DS, and so on. data, as our answer indicates. The answer is usually 
followed a torrent of questions about how to handle 
animation data. For instance, what kinds of bone 
motions are possible — keyframes or every frame? 
Branching? Transitions? This issue requires a sepa- 
rate article to explain, but it’s very important. 



















6 Tech: For objects that have Tech: The 
Will ae) Oe moving parts, such as spin- usual 
objects always be ning wheels on a ou or anew are 
7 propellers on an airplane, 8-bit (palet- 
: moving? we need to know if the ted), 16-bit 
hl . spinning object will ever be (high-color) 
_ Programmer: Yes. seen still, which would or 24-bit 
oo require a second model (true-color). 
(blurred and still). | This issue 
: may be 
somewhat 
more con- 


Artist: How many colors is the target platform capable of 


fusing if the 






showing? eet 
going to be 


used on 
multiple 
platforms. 


Programmer: We’re using 16-bit color. 
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The Lost World: Jurassic Park 
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Graphics Libraries 
The SciTech MGL 32-bit graphics 
libraries give you direct access to 
any drawing surface so you can mix 
and match the SciTech MGL’s 
graphics routines with any of your 
own drawing or rendering code to 
come up with a high performance 
application in the shortest time. 
SciTech MGL primitives work 
identically whether you are rendering 
directly into VRAM or into a system 
buffer. Your SciTech MGL code is 
fully portable between DOS and 
Windows 3.1/95/NT versions (other 
OSs planned). 


New Since v.2.0 
¢« Seamless DirectX support 


¢ Return of ModeX support 

e More low resolution graphics modes 
for fast software 3D and digital video 

¢ Hardware scrolling/panning surfaces 

¢ Sample MGL Smacker Video Player 

e Watcom Win386 mode support 

¢ DJGPP 2.0 support 

¢ Borland Delphi Support 


Includes SciTech MGL/Lite 


¢ Only initialization/setup functions 
e Perfect for custom rendering engines 
e Smaller footprint, less code 





_3.1 supports 
transparent 
sprites 


SciTech 
MGL 3.1 lets 


W® Windowed Fox & Bear Demo 


70.4tps — 


you use 
hardware 
acceleration 


320x240 Windowed 





Sees Scitech MGL 3.1 


ee men eet aby og Sd 
ie erat 


does on-the-fly 
color space 
conversions 


. 


Fully functional evaluation versions of 
SciTech MGL can be downloaded free 
of charge from our web site. Or, call our 
toll-free number and we will send you an 
evaluation CD-ROM. You pay only 
shipping and handling charges. Those 
charges are fully applicable toward 
purchase of SciTech MGL within 30 days. 
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Highly oes ae bit aceompbler 


rasterization 
¢ Color depths from 8 to 32-bits per 
pixel 


¢ Resolutions from 320x200 to 
1600x1200 

¢ DOS or Windows 3.1/95/NT versions 

¢ Full screen graphics under Windows 
using WinDirect (Win 3.1/95) or 
DirectX (Win95/NT) 


e Supports all standard C/C++ compilers 


¢ Automatic detection and utilization of 
VGA, VESA VBE 1.2/2.0, VESA 
accelerator (VBE/AF), WinG, 
CreateDibSection or DirectX 


2D drawing capabilities: lines, 
rectangles, circles, ellipses, polygons, 
triangles, quads, vector fonts, bitmap 
fonts, bitmaps, transparent bitmaps, 
arbitrary regions and mouse cursor 
support. 


3D drawing capabilities: 

lines, triangles and quads with flat 
shading, gouraud shading, 

16/32 bit zbuffering 
and 8 bit RGB 
dithering. 





For a free demo, 
to order, or to locate a reseller call 


(800)486-4823 (cx 053) 


www-.scitechsoft.com 


505 Wall Street, Chico, CA 95928 e Phone (916)894-8400 © FAX (916)894-9069 « Email: info@scitechsoft.com 


© 1997 SciTech Software, Inc. All Rights Reserved. SciTech MGL and WinDirect are tredemarks of SciTech Software, Inc. 
Quake is a registered trademark of id Software. All other trademarks are the property of their respective owners. 
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Artist Are there any palette Psych: The terse response here is because the previous 
answer pretty much guaranteed that this question wasn’t 






issues of which I should relevant — 16-bit color almost never has palettes. The pro- 


2 grammer probably thinks less of the artist now; a better 
be aware? 






way to ask this might have been, “I know 16-bit usually 





means no palette; are you doing anything special about 


Programmer: Nope. 






palettes?” 

Tech: This question always applies when the game uses 8- 
bit color. Again, this issue is too complex to explain fully 
here, but it’s a very key point and there aren’t many stan- 
dard ways of handling palettes. The artist needs to know as 
much as possible about how the game’s palettes work — 
specifically, how many (if any) of the colors can the artist 
dictate values for, how the fade tables work (if they exist), 
what happens when the lighting changes the colors, how 
to swap palettes, and so on. Also, the concept of palettes 
could be applied to higher color depths; even if we’re in 
16- or 24-bit, we may have to deal with palettes. 






: Are there any “special” | 


colors? Transparent 






colors, for instance? 








Nope. 


Tech: This question refers to colors that are handled by some special method. For example, 
some graphics engines consider any pixel that is pure black (RGB = 0,0,0) to be transparent, if 
the material has any file name under the “opacity map” setting. Palette-based systems often 
use certain palette entries for flashing colors, color-cycling, and numerous other effects. : 


Psych: Another terse answer — this may be because 
the programmer’s irritation (read: loss of respect for | 
the artist), which resulted from the last question. For 
example, the programmer might assume the artist is 
using “color” to mean a palette entry, not RGB val- 
Artist: What kind of lighting will be used ues. If so, “nope” would mean, “No, dammit, we're : : 

not using palettes,” rather than, “No, we’re not doing 

in the game? any special-effect colors.” Again, the solution is to. 

demonstrate knowledge of the issue in the wording of 

the question. CC 









Programmer: Static point-sources. Actually, 


“static point-source lights with 

Tech: As you can see, the, information relevant 
to this question includes the lighting type 
(point-source, directional, ambient), how to set 
these lights, and whether the lights can change 


LIGHTS.DAT file using the format during run time (dynamic) or not (static). 


lightname, X YZ, Radius, RGB, falloff. 


ambient” is more accurate. 


Lights must be defined in the 


Tech: If dynamic lights are supported, the artist 
will need to know how to define their animation. 
supported. Hopefully, the artist can simply animate in the 
modeling software and export that data — but it 
doesn’t always work that way. 

Psych: Oops! This is another question that seems 
to demonstrate artist ignorance. The previous 
answer said that the lights are “static,” meaning 
not animated. More loss of respect for artist’s tech- 
nical knowledge... and perhaps rightfully so. It 
would seems that our artist really doesn’t know 
what static means. The artist probably should have 
Programmer: Dynamic lights aren’t supported. asked the programmer to define “static” when the 
term was first brought up, rather than stumble © 
ahead as if it were all understood. 


Multipass lighting is also 


Artist: 








How should dynamic lights be 


animated? 
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Artist: How should I create multipass 
lights? 
Programmer: Create separate geometry that is 
coincident with, but simpler 
than, existing geometry. Map it 
with the lightmaps and name it 
MP-OBJNAME. At run time, this 


model’s rendering will be multi- 


plied with the basic model. 


What kind (if 















any) of texture 
mapping is sup- 
ported? 


Perspective-cor- 










rected, no run- 


time filtering. 


How much texture-map 
memory is budgeted? 
You have 2MB of tex- 


ture memory 


What size and shape can the 
texture maps’ dimensions be? 


Programmer: They’ve got to be 16x16, 


32x32, 64x64, 128x128, 
25652596, OF 512X512. 
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Tech: There are many ways to handle multipass light- 
ing input, and no real standards except QUAKE, 
which only really works for QUAKE or QUAKE 
clones. The programmer’s answer is a simple 
example; real projects are usually different. 
Psych: By bringing this issue up, the artist is 
wisely exploring a part of the program- 
mer’s earlier answer that wasn’t fully 
explained. The principles of multi- 
pass lighting aren’t usually part of 
normal 3D modeling software, so 
this issue could probably use 
some more discussion, and 
even a simple test of the 
procedure. 


Tech: It’s a rare game that doesn’t support texturing. There are 
several kinds of texture mapping possible, each with different 
tradeoffs between rendering speed and distortion. 


Tech: Obviously, the texture-memory limit affects 

how large and how many textures we can use. This 

is a pretty typical limit for 1997 graphics accelerator 

cards — usually, developers are limited to the tex- 

ture memory on the card, which is often 2-4MB. 

Psych: This question is a really important one, and 
the artist should make a 
strong effort to get as accu- 
rate a number as possible. If 
the producer is technical 
enough to answer mean- 
ingfully, the artist should 
probably ask the producer 
first. If it can be done 
casually, it would be 
worth exploring the 
memory situation with 

the programmer a bit — asking what is in 

memory, if the Z-buffer uses VRAM, and 

other topics out of the scope of this article. 


Tech: These numbers are pretty restrictive — 
artists would prefer nonsquare textures (such as 
64x16) and nonpower-of-two sizes (such as 
234x11), because it allows the artist to be more 
efficient in using the texture memory. 
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Hl aon Coltvelemuerlanuolempynescarleeneelau, 
artist connection is difficult for 
many artists. I’ve often heard artists 
complaining about trying to work 
with programmers, saying such things 
as, “They have no idea that they just 
ruined the whole look of the game with 
that limit!” 

- | think there is often a disconnect at 
two levels: One is an important differ- 
ence in goals for artists and program- 
mers, and another is the garden-vari- 
ety difficulty in communicating with 
which all team members must cope. 
Let’s explore the first disconnect in 
detail. Artists generally encounter two 
common problems when working 
with programmers (here come the 
stereotypes!). 


























FEATURE CREEP. “Feature creep” is when a 
product continually gains new features 
that weren’t in the original design. 
This happens a lot with games, and it’s 
often driven by programmers’ 
improvements. 

Why? Game programmers are very 
(eo) 0a) oLuene dom iyieemer-(eemeluelaueleremuele 
score is often measured in features, not 
in depth of game experience. For 
example, I know high-profile coders 
that don’t respect Myst because it isn’t 
technically innovative. Lots of artists 
that I know think Myst is a successful 
game that has a powerful impact on its 
users. This extreme focus on the tech- 


_ nical abilities of the game leads to 


ever-greater features, sometimes even 


at the expense of the overall game 


experience. By comparison, artists are 
more focused on the overall effect of 
the game: Commercial artists have 
been trained to impress their audience, 


not their peers. 
“FIELD OF VIEW.” Programmers can lose 


_ the forest for the trees very easily. It’s 


an occupational hazard — they have a 
death grip on microcosmic detail, and 
getting that detail to function is one 
of their primary tasks. This extremely 
heads-down approach means that it’s 
hard to keep the overall importance 
of their current task in mind. For 
example, a programmer accidentally 
makes a renderer that generates cool 
lighting streaks when the player rolls. 
In the code, this looks like a mistake, 
and so the programmer fixes it... and 
kills a potentially valuable addition to 
the game. 

Deciding what features to develop is 
really a technical design issue, not a 
(efofeb sere teeye)(oet(oole-televemecee (are 
Nonetheless, an industry tradition has 
arisen around this issue. In the early 
days, programmers designed and built 
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NUVISION 3-D SPEX. 
3D EO 





realism serious gamers crave. It's easy to implement and ready for your DirectX and 

DOS games today. 
3-D SPEX stereoscopic eyewear brings your customers the same high-performance, 

lightweight, stereoscopic viewing technology used for over ten years in military and 

industrial applications. Crisp, three-dimensional depth cues literally wrap gamers 

into the action. If your game is great, it'll be killer with 3-D SPEX. 

Open your eyes to the real thing in 3D: experience the best 


kick-butt stereoscopic 3D you've ever seen. Contact . a 
us at www.nuvision3d.com or 1-800-920-9327 





and ask for your Windows’ 95 or DOS SDK. 


Copyright © 1997, NuVision Technologies, Inc. All rights reserved. 3-D SPEX™ is a trademark of NuVision Technologies, Inc. All other tradenames are the property of their respective owners. 
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1d oXomn Vs oe) (omexcbeatcr- Deke mleleleeseler-Ceccemelele 
oldelomorvunmerecalecelvelmeslar-bugmlmeele 
end — not an ideal arrangement for 
the artist. Today, programmers are part 
(oe) mr eCa ad Coy oyectaelanccr-veebmoleiandelarae)acael 
decide the game’s features and capabil- 
ities, sometimes without the benefit of 
an artist’s (or level designer’s, or sound 
producer’s, or a host of other develop- 
ers’) input. 

THINKING VISUALLY. Programmers don’t 
idobeev. qtemdelonylelomwnierlmccseehen 
artists. As an artist, this point is driven 
home when I watch a programmer 
work. Standing over a programmer’s 
shoulder, watching endless streams of 
text scroll past, I can see that the visu- 
ally plain text formatting is not a sig- 
ebbaterDelm@oy-Ueulousbemdel(aouerele(anje-peler 
ing. Of course, artists understand 
complexity — I’ve seen programmers 
shake their head as they watch an 
artist thoughtfully rotate a nightmare 
tangle of wireframe lines and points, 
then suddenly pounce on some appar- 
ently-problematic intersection. Both 
types are skilled at very complex, sub- 
tle problem-solving — the difference 
I’m emphasizing is the appearance. 
Artists understand visual problems, 
even if they’re quite symbolic in 
er-UAUbnammr-b Oem o)uelau-beobeeommaenbel qoel 
procedural flows that aren’t necessari- 
ly visual at all. 

How ArE GAME PROGRAMMERS SIMILAR TO 
Artists? Programmers and artists are in 
a similar role: They’re both major play- 
ers on the frontline of development, 
caught between the realities of time, 
features, and managers’ expectations. 
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OW ela oy verelececmdelem-Leaer-)mopuelele (eum tare| 
that makes them peers in the end. 
They have similar issues with mile- 
stones and deliverables, and also have 
similar knowledge and attitudes about 
the rest of the game production cycle 
Goet-bu <cabelamethjouloeieleemmerniceelamyric 
hye eelevemmrbelem eme)eoe 

Both coders and artists are perfec- 
tionists, with their names in the cred- 
its. They usually believe in their own 
abilities, have a strong desire to pro- 
duce a top-notch game, and are will- 
ing to work hard to do it and fight for 
what they think is important. For 
example, in real-time games, frame 
rate is a very important issue to both 
artists and programmers. They’! both 
aXe) Maiveloemactaburct-veslpucnehw- lar. ielhio ce 
able ten frames per second, and they’ll 
joke) det ot hucmvelelem beh irdelne-belemeacae| 
Zo) Leb elcamcomberleuehvomeetnyiacrleleen 
S Webi meoyesbecbiscetootannw-meepeoveelevemeleyelec 
ing point for 
artists and 
coders — they 
develop 
respect for 
each other’s 
dedication 
(without the 
danger of feel- 
ing competi- 
tive), some- 
times 
expressed as a 
shared scorn 
for “slacker” 
nine-to-five 
workers. 


Like many spe- 
Cialists, artists 
and program- 
mers can fail to 
bbeleCanie-velemayer-ne 
specialized 
knowledge they 
have. For exam- 
ple, professional 
artists have 
unusual training 
and talent that 
lets them see and 
express visual 
beauty. 
“Unusual” 


means most people don’t have this 
ability. Still, most artists that I know 
take this skill for granted, and find it 
frustrating when other people (say, 
programmers) ignore visual beauty. 
Sell wr-vel qoymerere(ouje-velelbermnmeel—puelel: 
of many communication problems, 
and yet both programmers and artists 
share it. 


’m sure you think that’s all very 

bole ucnjebelcam oleianiyer-lace-bemluehinmele) 
woe eeyenedVomastemyiaeriele) eng 

OT meole(aumecemevele(amie-velemelers 
issues. For example, if you need more 
texture memory, don’t just beg for 
sesLe) noma) OLOd ums ela eemerucvestlelem@olenaperelt 
faked) “before” and “after” textures so 
they can see the benefit of an 
improved texture and weigh it against 


eS ieee ined 


the cost of the memory usage. If you 
can show a dramatic improvement, 
they'll be trying to figure tricky ways 
to get that cool art into the game. Be 
aware of the level of understanding 
that programmers have for varying 
parts of your work; don’t explain con- 
cepts they already understand. 

Be assertive about artistic judgment 
issues — remember, you’re the expert 
at that. If a proposed feature doesn’t 
EYe (em cetera emcomeslemaehwieseueeaslemy- bane 
and recommend that it not be imple- 
mented (expressing this dissenting 
opinion without causing strife is tricky 
indeed!). In a similar vein, be respect- 
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awe = ee 


ful of your colleagues’ fields of exper- 
tise, unless you have very solid rea- 
Noehmcomeceltlolmastarse 

Keep programmers in your loop. 
Consult with them, in their terms, 
especially about issues that affect 
performance. For example, if you’re 
trying to create an army of 100 
action figures, but your face count is 
too low, show a programmer a 
sketch of the scene you want and: 
run through a frame-rate calculation 
with them (“O.K., so 100 figures 
means 8,000 faces. The performance 
of 1,000 faces per frame means....”). 
This provides a reality check (and a 
roveCem ith iataler-tacesembarbehve)elamenecans 
aCoyehmcelesmerae ny (eye per-belemiar-UNiem secon 
the programmer a chance to suggest 
an innovative solution. 

Stay in your programmers’ loop. 
Excellent artists know the limits of 
dalapupeeleutbreomecemeitiacom ivetimeelar ine 
form. Also, tech-savvy artists can see 
tence araelemestiaelonne lene 
Becoming technically savvy isn’t diffi- 


eiel Laps a ole mer bem ibelem-Waulaeveukmecsert 
municative programmer. 

Don’t waste excessive hours 
PYaCehnannyoercmeveneesloeucvelmemereteataicae| 
issues. If you have a hard time distin- 
guishing, don’t suppress your queries, 
lo}tbiarelomeeyeteretomuslaeemeomletel@etienselcmeyy 
off-hour conversations. 


Features vs. Beauty 


nl ere’s my theory: In general, pro- 
grammers must balance features, 


okaucoyuset-veCQomm-belemates( mem aela mic rent 
the most capability, at the best frame 
rate, within their deadlines. On the 
other hand, RT3D artists are trying to 
balance artistic quality, performance, 
and time — they’re trying to get the 
best looking art at the target frame 
rate, within their deadlines. This dif- 
ference is the root of many program- 
mer/artist woes. 

In the worst case, coders push for 
features without caring if the game is 


ole all ClyNCLiTs 
Ctr eli! CE) 
Mocellig OGetnie 


Developinent needs 


mk 
3 t O5se, 
33 ee a8 88. 


RN Ne a I 


any better, while the artists ignore 
these new features as they build 
ele view buan vey @remeclormeiyemic hie 
SW etoraeCovemme li qesltcaemeleiutermelaya(e) op 
ment, then try to integrate their work 
at the end, which climaxes in a grand 
fight when the game sucks. 

©) Mero ltbu. ore ian wo lelaseleucst-lib ane) 
bleak. Programmers implement fea- 
tures that allow the game to show bet- 
ter looking art without compromising 
frame rate, and artists take advantage 
of these features to produoable. & 


Josh White (josh@vectorg.com) has 
been building real-time 3D models for 
games since 1990. He runs Vector 
Graphics (a company devoted to creating 
RT3D art), cofounded the CGA (a com- 
munity of computer game artists — 
www.vectorg.com/cga), wrote Designing 
3D Graphics, the first book on real-time 
3D modeling, gives lectures at CGDC, 
and writes about computer artists... but 
he admits that all this really kills time 
between soccer games. 
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@ Create 3-D action, adventure, role playing games and publish them royalty free! 

@ Contains World Editor and ACKNEX 3-D engine - no programming skills required 

@ Free 3-D template game with 150 free textures, sounds, weapons, enemies included 

@ True vector-based topology (no tiles!) for creating slopes, bridges, dungeons, 
multi-floor buildings; insert your own objects, actors, enemies, traps, and weapons 

@ Lightsources, light direction, ambient shading, transparent & translucent textures 

@ Objects can be manipulated with the mouse (e.g. to collect them in an inventory) 

@ Piayer can walk, drive, fly, climb, swim, dive... with realistic movement physics 

@ Self-defined titles, menus, overlays, panels and scrolling text on up to 16 layers 

@ 320x400 smooth scrolling VGA resolution, 8-channel stereo sound, midi support 

@ Imports PCX, LBM, WAV, MID and IBK files 

@ 200+ page English manual with game tutorial 


3D GameStudio lite $9 ¥ 


Prices #$20 overseas shipping 
More information, demos, ordering: 


+ http://www.conitec.com 


D-64807 Dieburg/Germany * Dieselstr. 11¢ * Tel +49 6071-9252-0 * conitec@aol.com 
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etworked computer games present new 
data distribution challenges to the devel- 
oper. With stand-alone games, all game 
information is available in one place, on 
one computer, all the time. When design- 


ing networked games, however, the devel- 





oper has to consider what information the 


other players on the network need, when 





si they need it, and how to deliver it to them. The easy way 
1 S f a out is to broadcast everything you can think of to everyone 
on the network as often as possible. This keeps everyone 
synchronized, but quickly consumes all available bandwidth 
8 — not a good idea for groups of players dialed in to the 
r G UF « E Fi ce S$ G r Internet. The other extreme is to carefully consider each 
packet of data and to send it only to other players who really 
need it. This approach makes efficient use of bandwidth, but 
deciding who needs data and who doesn’t chews up so 
a et W © E ke c many of the sender’s CPU cycles that no processing power is 
left to play the game. 
There is a middle ground, however, and it’s called “group- 
e ing.” Grouping allows networked games to route essential 
G ay , oe “ data among the players while making efficient use of both 
network and CPU resources. In some cases, underlying net- 
work service providers support an efficient way to distribute 
grouped data; this is called multicasting. In other cases, 
games may be limited to broadcast or point-to-point connec- 
tions. Still, grouping can provide some efficiencies. 
Grouping can help a networked game scale up to include 
large numbers of players. This article covers logical ways to 
group data and the schemes used to implement grouped 
communications. 


What Is a Grouping? 


he first thing to consider is why you’d want to group 
data at all. If you’re developing a one-on-one boxing 
game played on two computers, then chances are both play- 
ers will need to know everything about one another; every 
move and every change will need to be exchanged. It’s a 
very different situation, however, if you’re building a large- 
scale space war scenario with lots of players. You may have a 
very high-performance spaceship and may be doing rolls in 
seven dimensions, but if I’m far away from the maneuvers, 
you just look like a dot to me. You're too far away for me to 
see your detailed maneuvers, so I don’t need to know the 
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details of your motion. 
Furthermore, if neither 
one of us can see the 
“cloaked” alien spaceship 
hovering nearby, then 
there’s really no need for 
him to send us his posi- 
tion at all until he 


becomes visible. The bot- One 
tom line is that if you L] } send" 

; ui J / 
think about various play- »( Multiple 


ers’ data requirements, \ "receives™ 7 
you can save a lot of 

bandwidth, network 

interrupt overhead, and 

CPU processing by only 

sending information to 

the players who need it. 

The trick is to make rout- 

ing decisions without 

spending more cycles than you stand to save. 





How Is Grouped Data Transmitted? 


& efore we get into the mechanics of creating data 
groups, let’s look at how grouped data can be distrib- 
uted among computers on a network. Ordinarily, each 
sender can communicate with other players on the network 
using either broadcast, one-to-everyone communications 
such as UDP/IP or via one-to-one links such as TCP/IP. For 
computer games, what you really want is one-to-many or 
many-to-one communications. Multicast-capable networks 





FIGURE 1. Multicast transmission vs. server message exploding. 








(43 


group in DirectPlay, any player within a session calls 
IDirectPlay3: :CreateGroup. After a group is created, any of the 
other players in the session can join the group via the 
IDirectPlay3: :AddPlayerToGroup method or leave via the 
IDirectPlay3: :DeletePlayerFromGroup method. Any player can then 
send a message to all the other players in the group via a sin- 
gle call to IDirectPlay3::Send. Note that these interfaces don’t 
change with the underlying communication mechanism of 
the service provider; rather, DirectPlay abstracts away 
whether a group is implemented as a physical multicast 
group, an exploder group, a broadcast that’s filtered on the 
receiver end, or some other mechanism. 


GROUPING ALLOWS NETWORKED GAMES TO 
ROUTE ESSENTIAL DATA AMONG THE PLAYERS 
WHILE MAKING EFFICIENT USE OF BOTH NETWORK 


AND CPU RESOURCES. 


implement this capability at the physical level, using 
addressing schemes that allow a single transmitted message 
to be routed to many receivers while being ignored by oth- 
ers, even others on the same LAN. Even in environments 
where multicasting is not available, or in server-based game 
environments, the server can still effectively implement 
multicasting. A single transmission is reflected (or “explod- 
ed”) back to multiple receivers, albeit with added latency. 
Figure 1 shows multicast transmission and its 
server/exploder equivalent. 

The DirectPlay component of DirectX that provides an 
abstraction of one-to-many and many-to-one messaging is 
called, not surprisingly, group management. DirectPlay’s 
group management methods provide the ability to define, 
join, leave, and send data to groups of players. To create a 
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by Jenne Aronunaon 


Assigning Data to Groups 


asic multicast technology doesn’t say anything about 
what types of groupings to use, and indeed, in 
DirectPlay any player can join any group. So how do you 
make best use of groups? The approach to take in grouping 
data is to come up with some easily calculable measure for 
each message and to route the message to groupings based 
on that measure. 

When looking at any piece of data, the game has basically 
three pieces of information that it can use to decide where 
to send it. 

1. The data contents itself (such as the geographic location of 
an avatar, what team the producing entity belongs to, what 
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FIGURE 2. Geographic grouping. 





markings it has, what entity type it is, 
what acceleration it has, and so on). 
This is called “data-based grouping.” 

2. The source of the data (that is, the 
place the data is coming from — 
either computer, site, player, or 
object). This is called “source-based 
grouping.” 

3. The destination of the data. In 
“recipient-based grouping,” data is 
sent to a group comprised solely of 
those players who are to receive that 
information. 

DATA-BASED GRouPING. Data-based group- 

ing is the most intuitive form of creat- 

ing groupings, and for many games, 
geographic sectorization is the most 
common form of data-based grouping. 

Under geographic sectorization, the 

virtual world is broken up into regions 

and data is grouped according to 
region. For example, in the scheme 
shown in Figure 2, 12 groups are used 

to segment the play area based on a 

rectangular North/East grid. Each enti- 

ty knows what region it’s in and sends 
its data to the corresponding group. 

Thus, the airplane shown in the figure 

sends data to Group 6. It’s important to 

note that entities don’t have to recheck 
their region location with every inter- 
nal update (that is, every time they 
update their position). If you know 

that a single region is 100 miles or 20 

light-years across, and you know how 

fast your vehicle can go, then you 
know the soonest you could possibly 
enter another region, and thus can 
postpone checking your region until 
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that time. The result is that geographic 
sectorization yields an inexpensive 
(because it’s infrequently calculated) 
way of creating groups of data. 

A player’s computer would control 
the flow of data to it by joining only 
those groups it cares about. For exam- 
ple, as shown in Figure 2, an entity in 
Region 6 might care only about entities 
in its immediate area, in which case it 
would only need to listen to Group 6. 
If the entity has a larger area of inter- 
est, it might subscribe to adjacent 
groups as well, in this case adding all 
the groups shown in blue. Of course, 
there’s a tradeoff in using simple 
groupings; data isn’t perfectly filtered. 
Let’s say the entity in Region 6 is inter- 
ested in all other entities within a cer- 
tain radius of its location, shown by 
the dashed circle around the entity. In 
this case, the entity still has to join 
groups covering the entire blue region 
and will get some extraneous informa- 
tion. In general, this is acceptable — 
the extra data just has to be filtered out 
upon receipt. 

Geographic sectorization is just one 
example of data-based grouping. In 
practice, any of an object’s attributes 
can be used to assign that object to a 
grouping. For example, my space war 
game might simply sort data into two 
groups: data for “cloaked” spaceships 
and data for “uncloaked” ships. Players 
who don’t have the ability to see 
cloaked ships listen only to the 
uncloaked group and therefore don’t 
waste time and bandwidth processing 


packets for ships they can’t see. 
Grouping can also be based on data 
type. For example, in a war game, you 
might have separate groups for land vs. 
air vs. sea vehicles. Chances are that 
submarines don’t care about individual 
infantrymen on the battlefield and can 
avoid having to ever see infantry data 
by using groupings. 

SourRce-BASED GRouPING. In source-based 
grouping, every source of data (where a 
source can be a LAN, a player, or even a 
particular entity) is assigned its own 
group, and every player then subscribes 
only to those sources that it cares 
about. Under DirectPlay, only one 
player per group would send to a 
group, though many players can issue 
IDirectPlay3: :AddPlayerToGroup commands 
to listen to the group. The problem 
then becomes one of telling the desti- 
nations what information is being pro- 
duced by each source and determining 
which groups to join? 

In some cases, this problem is solved 
simply by well-known sources of par- 
ticular data. For example, if there’s one 
computer that provides weather and 
terrain information for the entire ses- 
sion, then all other players automati- 
cally know to listen to that player’s 
group if they want to get weather 
updates. A more general solution lies 
in creating a special group, which car- 
ries very low frequency information 
about all entities or players in the 
game, to which everyone subscribes. 
Since all players subscribe to this low- 
fidelity data channel, they know rough 
information about all the entities in 
the game. They can then get more 
detail about the entities they really 
care about by subscribing to the 
groups representing the sources that 
they want to hear. One good thing 
about this scheme is that the number 
of groups used scales linearly with the 
number of sources. In principle, the 
“source” can be anything, including a 
single entity or avatar. A side benefit of 
this approach is that the low-fidelity 
group automatically gives each player 
enough data to create a rough, “radar- 
screen” picture of the entire play 
space. 

RECIPIENT-BASED GROUPING. Finally, we 
come to recipient-based grouping. This 
scheme is something of an inverse of 
source-based grouping in that in this 
scheme groups are created on the basis 
of recipients with common interests. 
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For this scheme to work, each sender 
needs to know which players might be 
interested in each message it sends out. 
Once a list of interested parties is 
known, the data can be addressed to 
the groups that represent just those 
destinations. 

As an example, consider a situation 
similar to that discussed under geo- 
graphic grouping. Once again, each 
player is interested in other nearby 
entities. This time, though, each player 
must send a message to all the other 
computers in the game saying some- 
thing along the lines of “I’m at loca- 
tion (x,y,z) and want to know about 
anyone within one light-year of me. By 
the way, I listen to multicast Group 
10.” This interest expression tells the 
other computers in the game what this 
player’s data needs are and what com- 
munications channel to use. Then, 
each other computer, when it’s about 
to send out information about its enti- 
ties, must look at the interest expres- 
sions from all the other players on the 
network and transmit the data over the 
proper multicast groups. 

This scheme carries with it some 
extra Communications overhead in 
that the data requirements of every 
player must be transmitted to every 
other player during the exercise. 
Fortunately, these interest expressions 
change rather slowly, so they don’t 
result in a large amount of information 
flowing between hosts, as is the case 
with dynamic game data. Recipient- 
based grouping can also use up the 
largest number of groups of all the pos- 
sible schemes, if you’re interested in 
creating groups for each possible com- 
bination of recipients. Recipient-based 
grouping can be expensive to imple- 
ment in terms of CPU cycles on the 
sending side, but unlike either of the 
other schemes, it can offer perfect seg- 
mentation of data (you receive only 
what you need, with no extra informa- 
tion). 


Dynamic Grouping 


ll of the grouping schemes 


described previously are based on’ 


static definitions of groups. For exam- 
ple, in the geographic sectorization 
scheme, the boundaries of Sector 1, 
and hence, the definition of Group 1, 
are defined before the game starts run- 
ning. This is the easiest way to imple- 
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ment groups, since group definitions, 
and consequently, choices about where 
to send or listen, can be hard-coded 
into the game. 

Sometimes, however, static group 
definitions don’t work out. Suppose in 
my spaceship game a heated battle is 
taking place in Sector 6. The remainder 
of space may be relatively empty, but 
there’s a lot of activity in Group 6. In 
this case, using groups doesn’t buy you 
much in the way of performance, since 
most of the players wind up sending 
and receiving Group 6 data. The solu- 
tion in this case would be to create 
dynamic group definitions. With 
dynamic groupings, each session 
would designate a player to serve as a 
group server for the session (under 
DirectPlay, this role could be filled by 
the session host). The group server 
monitors or infers traffic flow in the 
various groups and can dynamically 
redefine groups. In the spaceship game, 
for example, a group server might 
decide to break up Sector 6 into four 
smaller sectors. It might add new 
groups, sending out the new group def- 
initions to each player. If the number 
of groups available to a session is limit- 
ed, perhaps by the available number of 
physical multicast groups, then it 
might redefine existing groups (for 
example, by combining Sectors 4 and 
8) to free up groups. Figure 3 shows 
what the geographically sectorized 
space of Figure 2 might look like after 
being dynamically adjusted. The bot- 
tom line is that with dynamic groups, 


FIGURE 3. 


each player’s software must listen to 
group definitions as broadcast from the 
group server and modify its group 
memberships accordingly. 


Two Grouping Gotchas 


here are a couple of things to look 

out for when you use groupings to 
communicate among networked 
games. The first challenge is to under- 
stand the underlying transport mecha- 
nism used by the service provider to 
implement grouped communications. 
Certain implementations, such as serv- 
er exploders, impose additional com- 
munications overhead on grouped 
communications. In other cases, such 
as poorly implemented multicast dri- 
vers, the use of large numbers of 
groups can actually cause a decrease in 
performance. Unfortunately, most 
game developers have no control over 
multicast driver performance, as net- 
work drivers are part of the operating 
system. 

One important thing to look out for 
is the join/leave delay for groups. In 
general, group creation, joins, and 
deletes don’t happen instantaneously 
(in fact, group join/leave times are 
unpredictable, but are generally mea- 
sured in seconds); games must be pre- 
pared to forecast their data distribution 
needs sufficiently far in advance to 
allow time for joining and leaving 
groups. 

The other major problem you'll 
face with grouping is how to bring 


Dynamic adjustment of geographic grouping. 
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players up to speed when they join 
new groups. In a grouped, multicasted 
world, each player knows only a sub- 
set of the globally available data. 
When a player joins a new group 
(such as, when a spaceship flies into a 


fully avoid this problem. This is 
another situation where a low-fidelity 
data group (as described under geo- 
graphic sectorization) can be useful; if 
all players listen to the low-frequency 
broadcasted updates on the low-fideli- 





ported when compared to broadcast- 
based Distributed Interactive 
Simulation protocols. Current game 
SDKs, such as Microsoft DirectPlay, 
offer group facilities but don’t provide 
any support for group definition or use. 


new sector), some anomalous things 
can happen. If the player doesn’t 
immediately get all the information 
about all the data in that group (such 
as, the identities and locations of all 
the other ships in that sector), then 
he’s essentially flying blind for a peri- 
od; our ship can be blasted by anoth- 
er ship that we’ve never even seen! 
This is another case where it’s impor- 
tant to join groups well in advance of 
when you'll actually need their data. 
If, on the other hand, the game 
implements a mechanism to bring a 
new group member up to speed 
quickly, then a player who joins a 
busy group may immediately be 
flooded with information, resulting 


in packet loss or poor application per- 


formance. Any protocol to bring 
group-joiners up to speed must care- 


ty group, then they’ll have at least 
some idea of what to expect when 
entering a new sector. 


Putting It All Together 
a anaging data distribution across 


networked games is not an easy 
problem. Simple data distribution 
schemes don’t scale well, limiting the 
potential size of games. More complex 
schemes, such as the various types of 
data grouping, require more thought 
on the part of programmer, but have 
been shown to greatly increase the 
potential scale of games. In the mili- 
tary simulation world, the increased 
network and processor efficiencies 
resulting from multicasting/grouping 
have yielded an order of magnitude 
increase in the number of entities sup- 


Any game developer looking to create 
scalable networked games needs to 
consider efficient data distribution. 
The good news is that combining SDK 
grouping functions with group defini- 
tion concepts such as those described 
in this article can yield games that are 
suitable for large-scale play by large 
numbers of distributed gamers. Mf 
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Jesse Aronson is a software architect at 
Science Applications International Corp., 
where he designs war gaming simulations 
covering thousands of entities running on 
hundreds of computers across dozens of 
sites. He can be reached at 
jesse.s.aronson@cpmx.saic.com. 





Tne Next Wave in Interactive Audio 


@20 you're making an internet game, and putting it on a CD. 
You're supporting chat, which means half- or full-duplex 
recording... and voice compression... and voice-disguising 

DSP. The graphics look 3D, so the audio has to sound 3D. | 
You have room on the CD, so you might as well use it for a | 
studio-quality music track. 


Or maybe you're building an interactive story. There's so 
much audio content, that you need 4:1 compression. You 
want different compressors for speech and SFX. It's 
essential that the music change with the context of the story, 
no dumb loops. This rules out conventional digital audio. 
But, young JS Bach said he'll only author for MIDI if he can 
record the instrument samples. 


You could spend lots of time and money developing all this 
technology yourself. Doesn't it make sense to buy into a 
_ ready-made solution instead? 











(800) 410-0192 (orders) | 
(602) 917-3474 (tech) 
(602) 917-5973 (fax) 


Diamond Ware 


a” Www.dw.com 


f Developed by DiamondWare 
E Distributed by The Coriolis Group 


























GAME DEVELOPER AUGUST 1997 






Direction for 
Corporate 
Developers 


Find your way to increased productivity 
with Software Development! 


ay Soe a 


Configuration management 
y, Team development 
Object technology 

Intranets 
Testing 
Java 

..and more 


Svein 














http://www.gdmag.com 








Prepare to meet your maker! 








MicroScribe is an advanced 3D digitizing tool that empowers you with | eo 
the ability to quickly and accurately capture complex 3D models from = _ 
physical objects by tracing over their surfaces. 


rhe 


The MicroScribe-3D is a desktop system that easily connects to your serial port and 
runs on PC, Mac, and SGI platforms. MicroScribe is compatible with all your favorite 3D 
graphics, animation, and CAD software. Models created by MicroScribe can be exported 
in IGES, DXF, and other standard file formats. For details, call Immersion Corea at 
408-467- = or -_ 893-1160 or visit our Web site at www.immerse. com. : 





"The pees 3) Hanna-Ba 


Immersion — 
) Corporation — 

















longer pull you over. You will be given 
honorary degrees in fields you never 
heard of, and will regularly receive 
invitations to the White House. But 
first, you must write an easy-to-use, 
flexible animation system. 

For your first shot at 3D animation, 
you choose to animate a guy walking. 
So you ask your favorite 3D animator 
to give you a walk cycle — something 
simple like a guy walking five feet or 
so. And, animator buddy, please make 
the last frame lead into the first frame 
so the whole thing can be looped. 

This first shot at a walk cycle works 
pretty well. You rip the animation with 
your tools, put it up in your 3D anima- 
tion engine, and the guy walks five feet. 
But, at the end of the five feet, the ani- 
mation suddenly pops back to the begin- 
ning. Walk five feet, pop back, over and 
over. Obviously, this is the animator’s 
fault, right? The character should have 
been created to walk in place. 
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You complain to the animator, 
explaining the mistake. The animator 
just shrugs and removes all of the for- 
ward translation from the animation. 
This is fine by you, because you want 
control over your character’s velocity 
anyway. You put the animation up in 
your engine, and the guy walks in 
place. Adding a simple forward velocity 
gets him moving, and with a little bit 
of adjustment, the feet don’t slide very 
much. But something is still not quite 
right. Your animated character moves 
exactly like those boxy microwave 
oven, color TV, and refrigerator movers 
in Dire Straits’ old “Money for 
Nothing” video. The walk is complete- 
ly unnatural and robotic. It looks, well, 
computer-generated. 

So, maybe the animator was correct 
to give the character forward move- 
ment. Animators should be able to 
make a walk look the way it is sup- 
posed to look, and programmers 


sing a Base-Root 


ystem For Animated 
haracters 


Oo, you're programming a 3D game? Then you’ve 
left the world of sprites forever. You’ll have more 
freedom, better animation, and fewer headaches 
than you had in the sprite world. Your rent will go 
down and chocolate will taste better. Random peo- 
ple will stop you in the streets just to say, “Have a 


nice day.” Your laundry will do itself. Cops will no 


should be able to handle it. From the 
programmer’s point of view, it would 
be nice to simplify things, including 
complex, motion-captured anima- 
tions. A nice way to do this is by intro- 
ducing a “base coordinate system.” In 
addition, “linear velocity extraction” 
can solve problem such as our walk 
animation popping back five feet. 
First, let’s define some standards. 
When animators create walking crea- 
tures (hand-animated or motion-cap- 
tured), they’ll likely work with a floor 
as their reference — I’ll assume this 
floor is just a display of the plane z=0 
(Figure 1). The world is a right-hand- 
ed coordinate system where the posi- 
tive z axis is “up.” From the anima- 
tor’s point of view, the creature’s root 
node is at the top of its skeleton hier- 
archy; move the root and the whole 
creature moves in the world. This root 
is usually positioned at the creature’s 
center of gravity (for a human, the 
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root node would probably be the 
joint between the torso and the hips). 
For a nonexploding, nonstretching, 
skeleton-based creature, this root 
node is the only part of the anima- 
tion that will have changing transla- 
tions in x, y, and z, in addition to 
rotations. Other segments will have 
translations from their parent, but the 
translations will stay constant for all 
animation frames. Note that this 
means that in your animation data, 
you only need to store one transla- 
tion keyframe for all segments below 
the root. 


have a point defined for each frame 
that anchors the frames. Velocities for 
the character can be applied to one 
point, and as long as each frame’s hot 
spot is aligned with this point, the 
animations will appear correct. Our 
base coordinate system “hot spot” can 
be thought of as an approximate pro- 
jection of the root onto the 2D plane 
of movement. It will always be 
approximate, as we want to be able to 
move the base in simplistic ways 
while allowing the root to deal with 
the natural movement of the center of 
gravity. 


FIGURE 1. Zed waves hello. The 
Root Node is the white box. 





ANIMATORS SHOULD BE ABLE TO MAKE A WALK 


LOOK THE WAY IT IS SUPPOSED TO LOOK, 


AND PROGRAMMERS SHOULD 


BEABLETO HANDLEIT by Scott 


Consider the motion of the root for a 
character doing something as simple as 
walking. There will be a forward trans- 
lation as the character moves forward, 
but the root doesn’t move forward at a 
constant velocity in a natural-looking 
walk. There will also be translations to 
the left and right, as well as up and 
down. If the animation was motion 
captured, the root will move in all sorts 
of unpredictable (but natural-looking) 
ways. After spending so much time and 
money getting the animation just 
right, the last thing we want to do is 
strip out this natural movement. 

I’d like to introduce the character 
that will be used in all examples. Call 
him Zed. He’s a human-like figure with 
an 18-segment skeleton, pictured in 
Figure 1. Zed’s root is attached to his 
hips. “Zed’s World” is the world coor- 
dinate system in a fictional game. And 
Zed’s capabilities (or lack thereof) will 
determine whether Zed gets published 
or canceled. 


Introducing the Base Coordinate 
System 
he base coordinate system we 
would like to use serves the same 


function as a “hot spot” on a 2D 
sprite. For sprites, it’s convenient to 
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Our base coordinate system will be 
the parent of Zed’s entire hierarchy, so 
it is the parent of Zed’s root. The base 
will be used to translate Zed or to 
change his facing (rotation about his z 
axis). The root will be controlled by the 
animation data at all times, so we don’t 
need to worry about it. From a pro- 
gramming standpoint, we can simply 
view Zed’s general position and facing 
as the position and facing of the base. 

When preparing Zed for the base 
coordinate system, the animator doesn’t 
necessarily need to add another level to 
his skeleton hierarchy. However, there 
are a few standards that should be fol- 
lowed. A standard walk animation 
should start with Zed’s root squarely 
over the origin (as in, x and y are zero) 
and the z position of the root set so that 
Zed’s feet line up correctly with the 
floor (the plane Z=0). Zed should be fac- 
ing down the positive x axis. Zed’s left 
side will then point down the positive y 
axis. Whenever possible, the animation 
should end with Zed still facing down 
the positive x axis. 

When these animation standards are 
followed, we can add our base-coordi- 
nate system in Zed’s world. The base- 
coordinate system will always have a z 
translation of 0, and the x and y trans- 
lation will move the character around 
the floor. The z axis of the base coordi- 
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nate system will always be aligned with 
the z axis of the world, and the orienta- 
tion of the x and y axes (the rotation 
about z) will make Zed turn to face his 
foes. Zed’s root z position is controlled 
by the animation data, so if the feet 
look correct on the artist’s workstation, 
the root translation will ensure that the 
feet are planted firmly in Zed’s world. 
In Figure 2, the base is on the floor (the 
red and green axes), and the z transla- 
tion of the root (the white box) main- 
tains the foot’s relationship to the floor. 

Now Zed can be controlled in a very 
sane manner with the base coordinate 
system. Setting the x and y translations 
of the base to zero will put Zed square 
in the center of his world. Zed’s feet 
will be on the floor just as the animator 
intended. In addition, setting Zed’s fac- 
ing (rotation about the z axis) to zero 
will have him facing straight down the 
positive x axis. You can, at any time, 
examine the base translation and fac- 
ing to determine where Zed is and 
which way he is facing. 


See led Sit, See Zed Jog 


et’s kick back with a few examples 

before delving any further. Zed 
now has a base coordinate system that 
is always in the same plane as the 
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FIGURE 2. Base Coordinate system 
is on the floor. 





floor, even if he’s jumping or falling 
down. We can move Zed around the 
floor by moving his base, allowing us 
to apply a simple linear velocity at the 
programming level. The root, which 
we now know is somewhere just above 
the base, gets its translation and rota- 
tion from the animation keyframes so 
that it can swing and sway naturally, 
just as the animator intended. Note 
that if the programmer were control- 
ling the root directly, Zed would have 
no swing to his step, and his forward 
motion would be completely linear 
(money for nothing...). 

The simplest example is of Zed 
standing still after running away from 
some bad guys. The animator wants 
Zed to bend his knees and heave as he 
breathes in fresh atmosphere. This is 
fine, because the base coordinate sys- 
tem doesn’t move at all. As far as the 
base is concerned, Zed is standing still. 
The root moves according to the ani- 
mation data, but it is always generally 
over the base. 

What if Zed is so tired that that he 
has to sit down for a minute? That’s 
fine. Our base doesn’t move. The ani- 
mation keyframes take care of lowering 
Zed’s root so he can take a little rest. 

Later, Zed wants to do a little jog- 
ging. This is simple, too. We just play 
Zed’s jog animation, and we move his 
base forward at the appropriate veloci- 
ty (stored with the animation). Zed’s 
jog is sure to be a bit jerky, but as far as 
our base is concerned, it’s simple linear 
motion. 

Zed’s world would not be complete 
without some jagged spikes to leap 
over. In the case of a canned jump, the 
animator can supply us with all of the 
z translation we need. In the case of 
motion capture, the z translation will 
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be perfect, so we don’t want to lose 
that. The base coordinate still stays 
planted in the x-y plane. The root’s 
animation keyframes take care of ani- 
mating Zed’s z translation. 


Linear Velocity Extraction 


alking and running are two 
‘ee activities that Zed will do 
often. The natural way to animate 
these actions is to include the forward 
translation in the animation. For 
motion-captured actions, this transla- 
tion is already there, and it’s exact. By 
now you are probably wondering what 
happens between animations. If Zed’s 
run cycle makes him travel ten feet, 
won't his base be left behind? The 
answer is yes, but this is where linear 
velocity extraction (LVE) comes in. 

LVE is a processing step that needs 
to happen before Zed is introduced to 
his world. A full explanation of LVE is 
the topic of another article, but the 
concept is simple. If our animation- 
processing tool is presented with an 
animation that travels a significant 
distance, a velocity needs to be 
extracted from it — later we can add 
this velocity back into Zed’s world. If 
an animation travels nine feet along 
the positive x axis, and the animation 
is one second long, we need to extract 
a linear velocity of nine feet per sec- 
ond and store this velocity with the 
animation. Zed’s animation is created 
at 30 frames per second, so for this 
example animation he’s travelling at 
nine feet per 30 frames, or roughly 0.3 
feet per frame. This distance must be 
subtracted from each frame’s transla- 
tion when it’s processed by the pro- 
grammer’s conversion tool. The ani- 
mation will look as if it’s running in 
place until we add in the forward 
velocity. 

After LVE has been applied to an ani- 
mation, the rules for the base coordi- 
nate system will all apply. The root will 
always be approximately above the 
base. In addition, we haven't lost any 
of the subtleties of Zed’s motion. His 
center of gravity will still have a 
quirky, natural-looking motion to it, 
but at the programming level, all we’ve 
done is to move Zed’s base along at 0.3 
feet per frame. The result will look 
exactly as it did back at the artist’s sta- 
tion, and we programmers are happy 





because from our point of view, we’re 
just Moving a point around the floor. 

Horizontal motion (along Zed’s y 
axis) is handled the same way. The 
velocities stored with each animation 
contain an x and a y component, so a 
sideways strafe is just as easy as forward 
motion. In fact, motion in any direc- 
tion on our floor is handled easily by 
these velocities. 

The velocity extraction is only 
applied to the x and y axes, however. 
Simple z movements, like the canned 
jump described earlier, are kept in the 
animation and need no attention from 
us. We don’t need to worry about gravi- 
ty or the upward force of the jump. In 
Figure 3, we just let the jump anima- 
tion play out, and our base stays at z=0 
while the root flies through the air. Any 
x and y motion for the jump is taken 
care of by our extracted velocities. 


Controlling the Animation 


A nybody with any sense of game 
play knows that you can’t use 
canned moves in all cases. What if you 
want to give the player some control 
over his jump? What if Zed can trans- 
form himself into a giant superball and 
bounce around? 

The simplest way to add more con- 
trol to a canned animation, such as a 
jump (Figure 3), is to stick with the sys- 
tem described thus far. The distance of 
the jump can be varied by altering the 
velocity applied to the base. If the 
jump needs to go 10% farther than 
normal, then increase the applied 
velocity by 10%. If the desired landing 


FIGURE 3. Zed in an animated jump. 
Z-translation is controlled by the ani- 
mation. The Base is still on the floor. 
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LISTING 1. When Zed reaches the end of the initial leap-tuck animation, the base is 


hoisted up by setting it to have the same x, y, andz position as the root. 





void ZedGuy : :HoistBase(void) 
{ 


CurrentRootPosition=WorldRootPosition(); // Get XYZ translation of Root 
SetBasePosition(CurrentRootPosition); // Make Base position match Root position 


position is known, the velocity 
required to get Zed to that point can be 
calculated and applied to the anima- 
tion. A variance of more than 50% in 


the base is hoisted up by setting it to 
have the same x, y, and z position as 
the root (Listing 1). 

Zed is still controlled by translating 


What if you want to give the player some 
control over his jump? What if Zed can trans- 
form himself into a giant superball and 


bounce around? 


distance may start to look strange, but 
with two or three different jump ani- 
mations, a wide range of jumping dis- 
tances can be covered. 

Controlling the height of a jump in 
this way is not as easy. The z position 
of the animation is controlled entirely 
by the animation frames, and Zed 
won't follow a nice parabolic arc until 
his feet have left the floor. If the “fly- 
ing” portion of the animation is sepa- 
rated from the initial jump, however, 
the jump height can be controlled by 
scaling the z translation values of the 
root animation. This must be done 
carefully, as changing the scaling too 
quickly during an animation will 
make the jump look unnatural. The 
final scale of the z translation should 
make its way back toward 1.0 (the 
original scale) so that the root will 
line up correctly with the landing ani- 
mation. If the piece of floor being 
landed on is the same one that our 
base currently occupies, the landing is 
simple because the animation takes 
care of it. The feet will hit the floor 
solidly without any intervention on 
the programmer’s part. 

When full control is needed over 
Zed’s root, it’s time to hoist up the 
base. Let’s look at Zed’s superball 
move. When Zed transforms into a 
giant superball, he does so by leaping 
into a tuck position. From the tuck, 
Zed holds his knees, spins really fast 
about his y axis, and bounces when he 
hits the floor. When Zed reaches the 
end of the initial leap-tuck animation, 
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his base, but the root translations for 
all superball animations will be zero 
(that is, Zed is animated spinning 
around the origin). Zed’s x, y, and z 
position can now all be controlled 
completely algorithmically, but we 
have to worry about part of Zed possi- 
bly sticking through the floor. 
Algorithmically controlled animations 
are a special case, and collision detec- 
tion must be performed to make cer- 
tain Zed bounces when he should. 
When it’s time to transition back into a 
landing animation, we should wait 
until Zed’s hoisted base position aligns 
with the starting root position of the 
landing animation. When the landing 
animation starts, we unhoist the root 
by setting Zed’s base z translation back 
to zero and the animation’s root z posi- 
tion takes care of the actual landing. 


led’s Facing 


ow that the base system is up and 
running, Zed can be made to run, 
jump, or do anything else in any direc- 
tion. The orientation of the base x and 





LISTING 2. The JumpWithTwist maneuver. 


// Zed’s Base Facing starts out at zero 
Zed->Play Animation (JumpWithTwist) ; 


y axes (rotation about z) controls 
where Zed is facing. It also controls 
which direction he walks or runs, so 
the velocity that we add back to the 
base translation must be rotated to 
match the base facing . 

The base coordinate system is always 
approximately under Zed’s root, and 
the base is always facing approximately 
“forward,” as far as Zed is concerned. 
What happens when Zed’s animation 
causes him to face a different direc- 
tion? The answer is that at the end of 
the animation, the direction that the 
base faces no longer represents “for- 
ward” in terms of Zed. We have to syn- 
chronize the base with Zed’s root at the 
end of the animation. 

Synchronizing the base facing with 
the root facing only needs to be done 
in animations where Zed intentionally 
faces somewhere new in the world at 
the end of the animation. A good 
example is a jump with a half twist, 
where Zed jumps into the air facing 
forward and lands facing backward. If 
we Start this animation with Zed fac- 
ing down the positive x axis, Zed’s 
base will still face down the positive x 
axis at the end of the animation, but 
his root (controlled by the animation) 
will point down the negative x axis. To 
put it another way, Zed’s nose normal- 
ly points in the same general direction 
as the base; at the end of this anima- 
tion, the nose and the base point in 
opposite directions. The half twist was 
intentional in this animation, and we 
want to make it “stick,” so we have to 
force the base to face the same direc- 
tion as the root. 

How you implement base-root syn- 
chronization depends on your anima- 
tion system. If no interpolation is 
being used, the synchronization is 
straightforward. If you are interpolat- 
ing between animations, however, a 
new animation frame must be generat- 
ed at the root for proper interpolation. 
Listing 2 shows the JumpWithTwist 
maneuver in detail. 





// Zed’s Base Facing is still zero after JumpWithTwist, = the Root : Fabs is “Dackwards’ 


Zed->SetNextAnimation(StandReady) ; 


// StandReady will set the Root back to TOE causing Zed to flip 180 degrees 
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LISTING 3. The animation setup with the EnableBaseSyncWithRoot call. 


// Zed’s Base Facing starts out at zero. 





// Notify the animation system that the next animation doesn’t end vith Ted Facing forvard 


Zed->EnableBaseSyncWithRoot() ; 
Zed->PlayAnimation(JumpWithTwist) ; 


// After JumpWithTwist ends, the animation system will ayitetvenies the Base — to natch 
// the Root Facing. StandReady will then face down the negative X axis as expected 


Zed->SetNextAnimation(StandReady) ; 


// Zed is now standing facing down the negative X axis. 


The jump-with-a-half-twist anima- 
tion sequence should illustrate the 
problem we need to solve. The answer 
is to notify the animation system that 
JumpWithTwist requires a base synchro- 
nization with the root. After 
JumpWithTwist has finished, the anima- 
tion system must determine the x-y 
facing of the root and set the base to 
match its direction. If the next frame 


Listing 4 shows some pseudo code 
for a routine called BaseSyncWithRoot. This 
routine is called as soon as we detect 
that JumpWithTwist has ended (we know it 
should be called, because EnableBaseSync- 
WithRoot sets a flag telling us to do the 
synchronization). 

One of the basic rules for our anima- 
tions was that each should start and 
end with our character facing down the 


The base-root system will make many anima- 


tion problems easier to solve — you’tl be able 


to say “We can do that” far more often than 


you say “No way.” 
displayed is the first frame of the 
StandReady animation, the StandReady will 
face in the direction that we expect. 
However, if we need to interpolate 
between JumpWithTwist and StandReady, we 
need one more step. Listing 3 shows 
how the animation setup looks with 
Our new EnableBaseSyncWithRoot call. 

If we need to interpolate between 
JumpWithTwist and StandReady, the last 
frame of JumpWithTwist must be modified 
to offset the change we make to the 
base facing. Imagine what would hap- 
pen if we didn’t account for this 
change. JumpWithTwist would end, we 
would set the base to face down the 
negative x axis, and then we would 
interpolate from the last frame of 
JumpWithTwist. The problem is that the 
Orientation of the root in the last frame 
of JumpWithTwist doesn’t match the orien- 
tation of the base, so we have another 
180 degree flip problem. The solution is 
to copy the last frame of JumpWithTwist 
(for the root only) and set the x-y root 
to face the same direction as the new 
base facing. Now the last frame of 
JumpWithTwist can be played with the 
new, properly adjusted base facing, and 
Zed’s orientation will be correct. 


GAME DEVELOPER AUGUST 1997 


positive x axis. The BaseSyncWithRoot 
adjustment takes care of situations 
when an animation starts out accord- 
ing to our rules, but must end with the 
character facing a different direction. 


Are All the Problems Solved? 


he system described in this article 

can handle animations with or 
without velocities, and will even han- 
dles a case in which we don’t follow 
our own rules. Unfortunately, it would 
take another article to describe some 





of the more complex situations that 
you may need to deal with, but here’s 
an example to get you thinking about 
another fairly common situation. 

The BaseSyncWithRoot example only 
solves our problem when the base and 
root don’t face the same direction at the 
end of an animation. What happens if 
not only the facing doesn’t match, but 
the actual position of the base and root 
are way off as well? This can happen if 
Zed pivots on one foot. His base and 
root facing will not match, and the root 
will end a few feet away from where it 
started as well. A more complex 
BaseSyncWithRoot can handle discrepancies 
in translation as well as facing. 


And More 


here are many situations that 

you'll have to deal with in your 
3D animation system that won’t be 
completely obvious when you start 
writing code. Many of the bits and 
pieces of a full system have been 
brushed over here — the important 
thing to keep in mind is a design that 
is flexible enough to handle new 
problems. Starting with a good 
design can mean the difference 
between a publisher telling you that 
Zed will get some good marketing 
before Christmas, and a publisher 
telling you, “Zed’s dead, baby. Zed’s 
dead.” 

The author would like to thank Harold 
Merrill for working up the fine illustrations 
of Zed that accompany this article. 

Scott Corley is vice president of software 
development at High Voltage Software Inc. 
He’s getting married this August to a won- 
derful girl who actually thinks game pro- 


gramming is cool. He can be reached at 


scottcy@ripco.com. 





LISTING 4. Using BaseSyncWithRoot to synchronize the base and the root. 


void ZedGuy : :BaseSyncWithRoot (void) 
{ 


NewBaseFacing = WorldRootXYFacing() ; 


SetBaseFacing(NewBaseFacing) ; 


// determine the orientation of the Root — 
in terms of the world 


// Set Base Facing to this new Facing 


NewInterpolationFrame=CurrentFrame; // Get a copy of the current animation frame 
NewInterpolationFrame->SetXYFacing(NewBaseFacing) ; 
// If we now interpolate from NewInterpolationFrame, the character’s Root Facing 
// will match in the transition from the old animation to the new animation. 
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DESIGN DOCUMENT 


‘ve got to get product out. In the panic and dizziness, my head smashes 








against the CRT and next thing I know this genie whiffs up out of a vir- 

tual bronze-texture-mapped lamp and offers me three wishes. Without 

missing a beat, I answer, “I need... 

0s A great team of talented, skilled, and dedicated engineers and 
artists (including a very understanding wife) with strong interper- 
sonal skills. 

03> Enough time and money to allow for a mess-up or two. 

o> A first class design document. 

Once upon a time, when coding a game involved one programmer 


(and maybe an artist) with a take-it-as-you-go budget and a loose dead- 





line, documentation didn’t need to be taken so seriously. You knew 


B Y T Z Vv i F R E E M A Mi 
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what you wanted to make and you 
made it. If there were a few major 
changes along the way, the only one to 
complain was you. Nowadays, a thor- 
ough and readable document can 
mean the difference between a swift 
descent to budgetless Hell and a 
smooth ride to shrinked-wrapped 
Nirvana. 


How the System Works 


ost games go through three 
development stages, from con- 
cept to design to production. Think of 
them as “flash,” “paper,” and “grind.” 

In the first stage, the concept paper 
acts both as a letter to yourself — set- 
ting out your goals clearly so you won’t 
lose sight of them — and as a sales tool 
for whomever takes the product to 
market down the road. Sometimes, this 
stage involves a working mini-proto- 
type as well, which gives you a chance 
to experiment and revise your ideas. 

The intermediate stage of design 
involves a lot of discussions with 
artists, animators, musicians, and engi- 
neers — trying things out, and finding 
ways to organize and set down your 
ideas. 

In the final stage, production man- 
agement is often left up to some expert 
in moving trains and tracks without 
major collisions. The original designer 
may be an integral part of the team, 
but in many cases — especially in large 
companies — the designer ends up as a 
kind of outside consultant. 

Without question, the design docu- 
ment is where the original parent of the 
project exercises the most influence on 
how this little baby is going to grow up. 
Even if you, 
the designer, 
have decided 
to double as 
project manag- 
er, don’t 
delude yourself 
into thinking 
that you hold 
all the reins. A 
complex pro- 
ject involves 
many talented 
people. Skilled 
programmers 
and artists 
tend to have 





Documentation Stage 


Concept Paper 


Design Document 


Production Documents 


http://www.gdmag.com 





minds of their own. While you intend 
to create a horse, the artist may be envi- 
sioning a unicorn and the programmer 
a highly efficient camel. A good docu- 
ment ensures that you are all planning 
to make the same thing. A great docu- 
ment ensures you all have the same feel 
for the inner soul of this thing. Think 
of it as a big band jazz score — it puts 
everybody’s mind in the same place, 
even when there’s still plenty of room 
for the stars to improvise. 

Your document is a sort of interme- 
diary between your mind and the real 
world. It ensures that what you have in 
mind is something that the real world 
is able to handle, and that what you 
end up with will be what you originally 
had in mind. 

Finally, remember the adage to 
which any salty gamer will attest: 
“Great art is in the details.” Brilliant 
details flow naturally from the general 
gestalt as though they were present in 
that first flash of inspiration. But once 
you get into the hands-on implementa- 
tion, it’s easy to lose that spark. 


The Challenge 


pea rototyping parts of the project 
yourself is definitely a good idea 


— make whatever rough sketches you 
can. But again, it’s those details that 
count. The more details your imagina- 
tion can hold, the greater a masterpiece 
your work will be. 

Working from a document has a flip 
side, as well. Developing an exciting 
game has to be exciting. Some of the 
best parts of many projects were dis- 
covered in the heat of last-minute 
deadline panic. True, the pressures of 


|. The three stages of documentation. 


Contents 








Genre; target audience; description; 
most compelling features; market infor- 
mation; cost and time to develop. 
Description of the body and soul of the 
entire project, with all the details, and 
the method by which each element will 
be implemented. 









Time-management charts (Gantt, PERT, 
and so on); task database; budget 
spreadsheet; technical specifications; 
Q/A database. 
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time and cost budgeting don’t allow 
for perpetual reiteration of concept, 
but you simply cannot expect a killer 
game to come out of dry, predictable 
work. The challenge is to create a 
design document that will allow your 
project to tolerate surprise adaptations 
without losing the integrity of its origi- 
nal direction and scope. 


Ten Points for a Successful Design 
Document 


1. DESCRIBE NOT JUST THE BODY, BUT THE SOUL. 
If game development was just an auto- 
mated input/output issue — something 
like writing code and being able to pre- 
dict how it’s going to work — you 
could get by with a dry, descriptive 
document. The reality is that develop- 
ment is done by people, many of them 
creative people, who have their own 
minds; most will want to leave a stamp 
of that mind on everything they do. 

It works like this: You provide specs 
to the artists and discuss with them 
what to do. You then visit the pro- 
grammers and go over their specs. Both 
groups nod to everything you say. 

That night, around 2AM, just as the 
constellation of C++ is rising in the 
west, the programmer reaches a mid- 
life crisis and begins to think, “What, a 
geek programmer the rest of my life? Is 
this what my mother expected from 
me? Why, I can design a game just as 
well as anybody else!” And the hands 
keep typing code. 

Around the same time, the artist has 
just woken up before his machine, hav- 
ing fallen into a deep stupor while 
waiting for a complex 3D rendering to 
finish. Unsure and not really caring 





Purpose 


It defines the concept, scope, worthiness 
and feasibility; sells the idea to your client, 
publisher, employer, and venture capitalist. 
It ensures that what is produced is what 
you want to produce. 


It implements the design document on 
time and within budget. 
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whether he’s dreaming or is actually 
getting paid for all this, immersed in 
that wild world of artistic genius where 
fantasy and reality blend as one, the 
phosphors come together in ways pre- 
viously unimagined — certainly not by 
you. 

By the next morning, your horse has 
become a unicorn with two humps. 
With creative people, instructing is not 
good enough. You need to inspire. 

In your design document, don’t sat- 
isfy yourself with a detailed description 
of every article and nuance. Take time 
to describe the feel that the game 
should have, the purpose behind each 
element, the experience each user will 
have, and any other aspects of the 
game’s soul you can envision and 
describe. 

For example, say you're designing a 
shooter. You want to train your players 
to deal with certain challenges before 
they actually meet them, so you place 
less lethal mini-challenges a few steps 
in advance. You're going to have to 
explain that to everybody on the devel- 
opment team, so they’ll understand 
why certain things are where they are 
and why they work the way they do. 
That way, even if (read: when) your 
team toys with and mangles your ideas 
as they exist on paper, you can still har- 
bor hopes that the outcome will have 
the same or similar overall effect. Or 
maybe even better. 

2. MAKE IT READABLE. Go ahead, provide 
your people with full pages of 10-point, 
sans serif, 80-characters-per-line text, 
and demand that they read it. You may 
want to bundle Advil in the package — 
for those who actually take the pains to 
obey orders. 

I try to follow at least some of the 
guidelines of good page layout. 

e Plenty of white space 

e Serif font for body text 

¢ Bold headers 

e Spaces between paragraphs 

e Short lines of text 

e Direct the eye towards important 

material 

e Use a hierarchical, “2D” format (see 
what I wrote about outliners in the 
“Design Documentation Tools” sidebar) 

Many instances call for a table, 
spreadsheet, or chart. Use them and 
make them sensibly attractive. 

3. PRiorITIZE. Now that you realize that 
you're working with other conscious 
egos, you'll appreciate the urgency of 


tagging certain game elements as 
sacred. True, there are no guarantees, 
but if you use the tag sparsely enough, 
it may get some respect. But don’t stop 
there. As long as you're tagging ideas, 
you'll also want to distinguish between 
things that you intend to do and 
things that you'd like to do if time, 
budget, skill sets, and technicalities 
permit. 


Don’t just say, “At this point, users 
will have to press the jump key with 
the arrow key to climb the wall.” 
Describe what will happen if a player 
tries anything else. Explain why you 
think users will be able to figure out 
the combination that you’ve provided. 
Explain what about the environment 
suggests that it’s possible to climb this 
wall. 


Even when you provide animations and 
prototypes, put the concept into words as 
well. True, an animation is worth a gigabyte 
of words, but words can communicate in ways 


that animations can’t. 


Then there’s the trash bin — things 
that sounded great, but were trashed 
for good reason. Refer to them explicit- 
ly and explain the reason that they 
were trashed. If you don’t, I can almost 
guarantee that they will be resurrected. 
Here’s your list of tags: 

¢ Indispensable 

e Important 

e If Possible 

e Rejected 

You may wish to use visual symbols 
to represent these. Don’t rely on color, 
since documents aren’t always printed 
in color. 

4. GET INTO THE DETAILS. A document with- 
out details is useless. Generalities can be 
interpreted by anybody in any way that 
they like. “Thou Shalt Not Kill” meant 
one thing to Moses and another to a 
Spanish conquistador. Detailing whom 
you shouldn’t kill and under which cir- 
cumstanceswould have been more 
helpful. The same holds true for your 
document: Once you’ve described some 
practical details and given some exam- 
ples, your idea becomes more concrete 
— and harder to shove around. 

For example, don’t just say, “Bronze 
bird is invincible.” Describe exactly 
what happens to this creature in each 
possible instance of its being hit, and 
how it recovers afterward. True, if the 
animator has any spunk and artistic 
dignity, you can rest assured that he 
won't follow your specifications. But at 
least he’ll have a clear idea of what you 
want to achieve, and his modifications 
won’t seriously alter the related por- 
tions of the game. 


Again, your artist will come up with 
something else, perhaps something 
even more suitable than what you orig- 
inally conceived. That’s real success: 
When your developers’ results come 
out even closer to your original flash of 
conception than what you were able to 
descibe on paper. But this won’t hap- 
pen unless you first lucidly describe 
your concept. 

Don’t just say, “Bongo Man is 
stronger than Bongo Boy, but Boy has 
faster reflexes.” Use tables, spread- 
sheets, and charts to assign real values 
to the character’s speed of movement, 
how many hits the character can take, 
how much damamge the character’s 
hits do, how many cels it takes to ani- 
mate a hit, and so on. This sort of 
spreadsheet is invaluable in the Q/A 
and tweeking stages of production. 

Don’t just say, “Most people will fig- 
ure out the whole game in a few days.” 
Make a chart of predicted product life 
in different households, indicating at 
which points in time you expect vari- 
ous features to be discovered. User test- 
ing will later provide valuable feedback 
for designing your next game. 

5. SOME THINGS MUST BE DEMONSTRATED. 
Sometimes a few rough sketches are 
enough, but if the idea is truly impor- 
tant to your concept of the project, you 
may want to make a rough animation 
yourself. When behaviors of elements 
become too complex and ambiguous to 
describe on paper, you'll want to make 
a prototype. A side benefit of prototyp- 
ing is that this practice often leads to a 
simpler, more elegant solution. 
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Even when you provide animations 
and prototypes, put the concept in 
words as well. True, an animation is 
worth a gigabyte of words, but words 
can communicate in ways that anima- 
tions can’t. Words also clearly spell out 
the vital nuances that may be missed 
when watching the animation. 

6. NoT Just “WHAT” But “How.” In the real 
world, the “how” determines the 
“what.” For example, suppose you’ve 
opted for claymation. Work out the 
process of how the images will be cap- 
tured and document everything. What 
material and what color should the 
backdrop be? What camera should be 
used and why? What are the steps for 
processing the captured frames? And on 
and on. If you’ve tried it, you'll know 
that any one of these factors can have a 
serious impact on the end result. 

Or suppose you’re working on a 
motorcycle racing game. You state that 
the motorbikes must be balanced by 
their differing pros and cons. You even 
provide a chart that shows how bal- 
anced they are. Then you state that 
tweaking will be necessary. State how 
you plan to tweak — what is the 
process? Suppose the main character in 
your game is the Phantom of the 
Opera. Describe how theplayer’s key- 
board is mapped as a pipe organ. 
Provide a map of each key. Specify how 
many channels of sound will be avail- 
able. Talk it over with your program- 
mer and work out every detail of how. 
Then document it. Two different 
“hows” can mean two very different 
results. 

7. PROVIDE ALTERNATIVES. Project managers 
spend a lot of time with their Gantts 
and PERTs. Personally, I can’t really say 
that this stuff is effective for game 
development — principally because 
there are just so many unknowables. 
The more radical and pioneering your 
game technology, the less predictable 
the development stream is going to be. 
The best thing you can do to ensure 
that your team reaches your milestones 
on schedule is to provide more than 
one way of doing things. 

Lets go back to the keyboard as pipe 
organ example. Your engineer 
describes to you the ultimate method 
of getting awesome and funky results 
with tremendous power and depth to 
the user — at a cost of about 50 person- 
hours to implement. As with every- 
thing else we’ve discussed, you docu- 
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Design Documentation lools 


4. Lots of paper and pencils (nothing digital has yet replaced paper and pencil for hack- 


ing out ideas). 
2. Even more erasers. 


3. A good integrated document application that includes features such as: 

a. A good outliner. Most decent word processors have an outline mode. It’s amaz- 
ing how few people ever try out this feature. Some word processors will even 
automatically number and sub-number your items for you on the fly. An outliner 
makes it much easier to create documents in a nonlinear fashion, jumping 
around and inserting and moving information from place to place. An outliner 
also makes it easy to produce what I call “two-dimensional documents” — 
meaning documents that can be read both vertically and horizontally. Moving 
the eye vertically, a reader gets a feel for the contents and major concerns. 
Moving horizontally provides the reader with detailed information. 

b. The ability to link illustrations to text. 


c. Cross-reference updating. 
d. Spreadsheets. 

e. Tables. 

f. Hot links are great. 


| recommend Nisus Writer (Paragon Concepts) as the most powerful 
document processing tool, but ClarisWorks (Claris Corp.) is still the 
best integrated application available for both Mac and Windows. 
There are all sorts of project management tools available. | reserve 
those for the next stage of development. 
4. A prototyping tool. mTROPOLIS, from mFactory, is a killer for determining behaviors 
of objects and getting things to happen really quickly. Macromedia Director is still 
the standard for quick and dirty animations. You may also need a 3D modeler, such 


as 3D Studio. 


5. A basic library of sound effects. You don’t have to make the final decision, but you'll 
probably want to try a few things yourself and give your audio engineer some idea of 


what you want. 


6. Some pieces of art representative of the style that you intend to use. You'll probably 
need to make a list and use it to work with an artist while you are composing your 


document. 


7. A knowledgeable friend to read the thing over thoroughly once it’s finished and 
point out the remissions, contradictions, and ambiguities that every author fails 


to notice. 





ment the whole thing. 

You can’t stop there. You’ve got to 
ask, “What would it take if we just 
wanted a trimmed-down, eight-chan- 
nel pipe-organ? And what will we need 
to achieve the bare minimum? And 
what if we just had some assistant 
doing this?” And then you document 
all that as well. When the FedEx truck 
is on its way over for the final daily 
pickup, you'll be able to save your skin 
with a simple, “OK, do Plan C.” 

One of the biggest mistakes I’ve 
made in product design is asking engi- 
neers, “Can it be done?” Unless you’re 
asking a first-class programmer, the 
question is useless. More specifically, 
responses fall into one of three cate- 
gories: 

(Lousy programmer) “Sure, that’s no 


problem.” 

(Mediocre programmer) “Nope. 
Can’t be done.” 

(First-class programmer) “I could do 
it like this and it’ll take two weeks. Or I 
could make a slight modification like 
this and it’ll take five hours.” 

Always ask for more than one alter- 
native and an estimate of how long 
each will take. Then indicate your pref- 
erence — do this is if we have time, or 
this if we don’t. 

8. Give ITA LiFe. I’ve already warned you 
against strangling the inspiration and 
spontaneous creativity that comes with 
the excitement and fun of seeing ideas 
become living objects in your hands. 
You've got to allow your document to 
tolerate change — by you or by (hope- 
fully intelligent) others. 
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I first learned this lesson as a music 
composition major at the University of 
British Columbia. With much toil, I 
had written a neo-renaissance brass 
quintet of which I was quite proud. My 
professor liked it, too. When we 
brought it to the college’s star brass 
quintet for rehearsal, however, I passed 
through several stages of horror, disbe- 


lief, indignation, and clinical depres- 
sion within ten seconds. The quintet 
began to play, then stopped on signal 
from the tuba player. The fellow took 
out his pencil and began to change a 
few notes, and then everyone contin- 
ued. It happened more than once. 
My professor, noting my sudden 

faint state of health, turned to me and 


The Ecology of Improvement 


a.k.a. The Freeman 


Elegance-Gestalt Principle 


mproving the elegance of one part 
of an entity without addressing the 
gestalt of the whole will negatively 
effect the perceived elegance of 
every other part of that entity. 

For example, you just had the leaks in 
your car’s brake system patched, causing 
such pressure that your whole worn-out 
brake system blows out on you. Or you 
just bought a new pair of jogging shoes, 
which make your previously sufficient 
blue jeans look plain tacky. 


Mean line of 
elegence 


Line of ugliness 





New line of 
ugliness 
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Or you just found a way to add real- 
ism to the movement of one of your 
characters, rendering all other charac- 
ters jerky and sick in comparison. 
“Amazing,” you mutter, that pale look 
of what-are-we-going-to-do-now-real- 
ly-quickly all over your face. “They all 
looked great yesterday.” 

The lesson: Don’t consider change in 
one area without first considering its 
ramifications on every other part of your 
design. 


1) ; se 
L’ One element of your game is conspicuously inferior. 



















commented, “Don’t worry, they did 
that to Mozart as well. And they’re usu- 
ally right.” 

The fact is, no matter how good 
something looks on paper, the greatest 
expert still modifies things when it 
enters the concrete world of objective 
perception. Nevertheless, you don’t 
want to witness the ruthless rape of 
your design and dreams. Rather, you’re 
hoping for a kind of organic growth — 
ideas growing naturally out of the seeds 
you've planted without needing foreign 
limbs and bodies grafted onto them. 

Here are some tips for creating a doc- 
ument that can tolerate change with- 
out corrupting the original idea or sab- 
otaging the development process: 

e Make certain to engrave in stone 
those aspects that are so essential 
to the game concept that they 
must not be changed. 

e Make certain everybody under- 
stands the feel that the game is 
supposed to have and the purpose 
of each of its details. 

e If information is repeated, it must 
be cross-referenced. Otherwise, if 
there are changes, you can end up 
with contradictory instructions. 

And here are some tips for the actual 
implementation stage: 

e When a change is suggested, check 
back in your design document and 
see if it is in concordance with the 
“soul” of your game. 

Check whether this is just an isolat- 
ed change, or it’s of major global 
ecological impact (see “The Ecology 
of Improvement”). If it’s the latter, 
save it for your next project. 
Update the design document and 
include the reasons for the change. 
Or if you didn’t make the change, 
say so and explain why it was 
rejected. 

Changes, deletions, and rejected 
ideas should be retained in a mas- 
ter document to avoid discussing 
the same thing twice. 

e Everyone must be working from 
the same version. Past versions 
should be destroyed. 

¢ Crucial, Vital, and Urgent: The 
design document must be main- 
tained under one person’s supervision 
only. 

9. NOBODY SHOULD BE ABLE TO Say, “I Dip IT 
THAT WAY BECAUSE | COULDN’T FIND ANY 
REFERENCE TO IT IN THE DOCUMENT.” |’ve 
seen documents that didn’t even have 
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Anatomy of a Design Document 


ere’s a suggested structure for your document. In actuality, you’ll need to tailor the structure to suit your particular project. 
But my guess is that this example is pretty close to the industry standard. If you’re working with a team that you have a histo- 
ry with, or if the game is following an established precedent, your document may be as short as 30 or So pages. That’s short. 
Often, these documents can end up in the hundreds of pages. They’re getting longer and longer as the industry matures. 





Overview (sort of a recap and revision of the original concept paper) 
The User Experience 
¢ To what genre does this game belong? (We haven’t really defined genres yet in this industry, as they have in Hollywood, so you'll 
have to be a little more specific. Best to describe similar products.) 
¢ What part(s) of the brain are you attacking? (Reflex response? Imagination? Problem solving? Strategy?) 
¢ What are the most compelling aspects of this game? (Give this section much consideration. It is the core of your “mission state- 
ment.”) 
¢ How deep is the product? (Is this a one-shot deal for buyers, or something they can keep getting into for a while?) 
The Platform 
e Arcade, home, or school? 
e PC, Mac, console, or multiplatform? 


The Users 
e General audience (65) 


e Base target audience 
¢ Describe typical users 
Time 
¢ Game-play time (This is one of the most crucial, decisive issues in the design of any game. It’s impossible to make meaningful 
design decisions without establishing predicted maximum, minimum, and mean game-play times first.) 
e Product life (How many days/months/years do you expect the user to keep coming back to your game? This period is usually 
based on how long it will take users to figure everything out and master it.) 
Basic Concepts (gives a feel for the game, why things are the way they are, and what the essential, indispensable elements are) 
Storyline 
¢ The background story (if applicable) 
¢ Storyline or object of the game play 
¢ Rules of the game (Justify these rules and explain what you expect to see from them.) 
Heroes and Villains 
¢ Include biographical information and descriptions, even if this won’t be implemented in the software. This will be of great help to 
the artists and animators. 
Novelties and Compelling Features 
e This is your chance to state the things you could not bear to see disappear from this project, and justify your emotional attachment 
to them. 
Navigation Chart (an illustration of how parts of the game link to each other) 
Entry and exit 
Main menu 
Level movement 
Access to preferences and credits 
Global Behaviors (ensures that your game will have a consistent feel to it, avoids serious run-ins with the programmers) 
Run through all the standard elements of your project (Sprites, buttons, life-bars, input devices, and so on) and describe their behaviors 
in every circumstance you can imagine. Your programmers will shower you with wreaths for this one. Later, you can go change things on 
them — as long as the objects remain consistent, and everything is justified. 
illustrate the motion of each animation, at least in stick form. For 2D scrollers, fighters, and the like, you’ll want to describe things cel by 
cel. With other projects, rough sketches of general movements and their approximate duration in microseconds may be enough. 
if you are relying on a specific input device, justify your button-mapping and button-combination decisions. 
Scenes and Action (in an adventure game, this will take up most of your document) 
include preferences, credits, and main menu. 
In subchapters, lay out consistent behaviors of local elements. 
Very often, a storyboard (that is, a series of panels illustrating each scenario) is provided. In many projects, however, this is clumsy and 
impractical. 
Lists of Resources 
You’ ll have to go over this with a fine-tooth comb to make sure it’s thorough. Leaving out even a few items, or failing to describe them 
clearly, could prove a major source of exasperation later on. 
This section comprises detailed lists of animations, sounds, music, narration, sprites, backgrounds — everything that needs to be creat- 
ed besides code. 
Cross reference each item to its main reference in the document. 
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the pages numbered. And then they 
complain that people didn’t follow 
instructions. Every good word proces- 
sor will auto-number pages and print 
the date and title in the header or foot- 
er of every page. Some will even allow 


out HTML. But remember that more 
often than not, people prefer to work 
from a hard copy. (That way there’s 
something to read while rebooting 
after the hourly system crash.) 

10. DELIVER IT IN GooD ConpiTioNn. After all 


You may wish to write your document using 
HTML and provide hot links, but remember 
that more often than not, people prefer to 


work from a hard copy. 


you to change the header at new chap- 
ters. Use bold text to direct attention to 
important material. Repeat yourself in 
different parts of the document as 
much as you like, as long as you cross- 
reference so you can update everything 
together as well. Make a thorough 
Table of Contents. 

You may wish to write your docu- 
ment using HTML and provide hot 
links. Some progressive word proces- 
sors provide hot link capabilities with- 


NAME 

3D Labs 

3Name 3D 
AlphaPowered 

ATI Research Inc. 
Caligari Corp. 

CGDC on CD ROM 
Conitec Datensysteme 
Diamond Multimedia 
Diamondware 
Electric Image Inc. 
Immersion Corp. 
Immersion Corp. 
InstallShield Corp. 


MPG ‘97 
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this, you need to do whatever you can 
to facilitate everyone actually reading 
and using the thing. A pile of papers 
doesn’t get read — it doesn’t look 
important enough. Only things with 
hard covers look important. 

Create a list of everyone who is sup- 
posed to have a copy. Keep the list. 
Print out the whole thing with the date 
in the header of each page. Have holes 
made and put it in binders. Label the 
spine and cover of each binder. When 


NAME 





there are updates, provide everyone with 
the revised pages. At some points, you 
may need to provide new books and 
throw out the old ones. 


In Sum Check... 


Oovie makers use move scripts. 

Architects use blueprints. 
Musicians use a score. According to 
ancient hearsay evidence, even the 
Cosmic Creator created a design docu- 
ment — which He later let a few 
prophets take a peek at — before the 
primal “Let there be light!” So game 
developers, following their Supernal 
Role Model, can certainly do the same. 
Do it right and it’s smooth sailing the 
rest of the way. 

Tzvi Freeman teaches Game Design and 
Documentation at Digipen School of 
Computer Gaming in Vancouver, British 
Columbia, Canada. He has designed sev- 
eral commercial games and has acted as a 
consultant on many others. He can be 
reached at TzviF@aol.com. 
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ment to millions of lives. We have the following openings in 
our Marlboro, MA division: Join The Masters of the 3D Game. 
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section for jobs, products, and 

services. Don’t miss out on this 

incredible opportunity to hire your 

technical professional developers. 

Please contact Chris Cooper at 

415-908-6614 or by e-mail at 

ccooper@mfi.com with all your 
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are witnessing the birth of a new games 
medium — online games — that will be 
about people playing together. To be 
part of this new medium, we game 
designers are going to have to overcome 
the old system built around sequels and 
solo play. Most of us will be glad to be 
doing original work, but I believe we 
will first have to realize how obsolete 
many of our previous design instincts 
have become in this new online world. 

All of our features, imagery, and con- 
cepts as designers have gone to support 
the single-player game. But solo games 
have a wholly different style than the 
people-oriented games that will make 
up the online games medium. Solo 
games concentrated on entertaining just 
one user, So all the resources of the 
machine were devoted to that end. 

Brilliant graphics and sounds were 
used to set the scene for the player — 
making his (the market was 90% male 
in the solo world, but online it’s more 
like 60%) experience more compelling. 
Segues and cut scenes were triggered as 
appropriate to that audience of one. No 
provision needed to be made as to what 
the other players would be doing while 
the awards ceremony visuals were run- 
ning. In solo games, the “other players” 
were all AI stand-ins who would mind- 
lessly wait while the player gorged on 
eye candy. And the pandering didn’t 
stop with the player’s ego either; solo 
games needed to push the platform as 
well, since one of the biggest perks for 
many hardcore players was showing off 
their new hardware. 

The features of a solo game were 
geared to take advantage of the “learn- 
ing curve” involved in the process of 
mastering a new game and its environ- 
ment. Normally, there were whole 
groups of features (new levels, stronger 
monsters, and so on) that only showed 
up in certain environments as the play- 
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Escaping the Solo Trap 


’m aware of only one “multiplayer-only” game 


that was published by a major publisher — my 
own ROBOT RASCALS by Electronic Arts. There’s a 


reason. Solo sells. Or at least it has until now. We 





er advanced. This type of feature-heavy 
design also had an advantage over solo 
games besides player titillation. Design- 
ers could hide the limitations of the Al 
opponent behind a veil of added game 
elements that kept challenging the play- 
er when the opponent couldn't. 

Hiding the limitations of the artificial 
opponent led to a whole group of limi- 
tations in games. Although subtle 
nuances of pattern recognition might be 
trivial for a human player, even the 
most obvious pattern presents a night- 
mare for an Al. The code involved in 
teaching a war game AI to identify the 
“front” is incredibly complex anyway — 
imagine if some of the units are 
“unseen” or of unknown strength. 
Thus, the tendency was to make the 
externals of solo games very conven- 
tional (if not simplistic). Designers also 
discarded opportunities for interactions 
with subtle audio-visual cues in favor of 
algorithmic and concrete presentations. 
Rather than allude to something with 
patterns or sounds (the identification of 
which humans excel at), designers used 
the same sort of logic in their visual and 
audio representations as they used in 
their artificial opponent’s analysis of the 
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world. There were no “maybes.” There 
was only “true” and “false,” zero and 
one. In addition, the need for compe- 
tent AI required that the internal mod- 
els be computational (which computers 
“love”) rather than heuristic (which 
humans enjoy). In M.U.L.E., I varied the 
output of land if the adjacent plot was 
producing the same thing. This feature 
gave the Al fits, but it presented an 
interesting trade-off in land acquisition 
for human players. The better answer 
for a solo design would have been to use 
some simple mathematical equation. 

Taken together, these design ele- 
ments may make good solo games, but 
they conspire to make games that are 
poorly suited to humans playing with 
humans. Rather than “over the top” 
production values, online games will 
reward small downloads, good multi- 
player balance, and smooth play expe- 
riences. These emphases will preclude 
pauses for “cut-scenes” and pandering 
to a single player’s ego or hardware 
vanity. Since a person derives so much 
challenge from anticipating another’s 
actions, complex feature sets aren’t 
needed. Simple sets of rules that are 
consistent over time make multiplayer 
games more accessible. However, subtle 
nuances in the audio/visual presenta- 
tion of products make for much richer 
play experiences for human oppo- 
nents. And, finally, heuristic (rules-of- 
thumb-based) models are much more 
appealing to players than complex 
numeric systems, playing to the 
strengths of our brains without sacrific- 
ing playability. To be part of this new 
medium, designers will have to aban- 
don the solo model for design. If we 
can do this, we will be a long way 
toward making the kind of products 
that the online world will reward. @ 

Dani Bunten Berry designed and directed 
the development of twelve original comput- 
er games. Among them were ten multiplay- 
er games and three online games, including 
the first modem-to-modem game (MODEM 
WARS) and the first four-player network 
game (GLOBAL CONQUEST). Her best known 
titles were COMMAND HQ, SEVEN CITIES OF 
GOLD, and M.U.L.E. She is currently a 
design consultant. 
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The Best in Game Development Technology! 
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Smacker is a compressor for video, animation and sound data designed 


Cool Digital Sound Features: 
specifically for games. Smacker has been used in all aspects of game 


Multiple channel mixing (limited only by CPU power), volume 
control, panning, pitch shifting, hard drive or CD-ROM 
streaming playback, on-the-fly format conversion, and much, 
much more! 







design: cinematics, cut-scenes, video-sprites, transparent videos, 
image decompression, scrolling video backgrounds, and more. It has 
been used in over 400 games because it is fast (damn fast!), easy-to- 
implement, and available for most game platforms. 










Awesome MIDI Features: 








The Smacker SDK is available for DOS, 16-bit Windows, Windows 
95, Windows NT, Win32, Mac, and PowerMac. The Smacker SDK 

API is identical across the platforms and includes everything necessary 
to playback videos with synchronized sound. 


Looping, branching, triggered digital sound playback, 
tempo control, powerful MIDI callbacks, etc. 









Other Features: 


Extensive timer library, complete Red Book CD-audio support, 
built-in Win32s support, full DirectSound support, 

























For graphics, Smacker has built-in support for VESA 1.x (direct 
decompression into banked video RAM) and VESA 2.0 (linear frame 
buffer support). Under Windows, Smacker supports WinG, 
CreateDIBSection, DispDIB, and DirectDraw. For the Mac, Smacker 
supports both GWorlds (with lightning-fast assembly blitters to 
augment CopyBits) and direct-to-screen decompression. Since 
Smacker can decompress into any linear piece of 8-bit or 16-bit (new!) 
memory, using it with your own graphics code or a third party library 
(such as MGL) is no problem. 


complete Smacker support - play multiple sound effects and 
video sound tracks simultaneously! 
















Supported Platforms: 
DOS with Watcom or Borland. Windows, Win32s, and 
Windows 95 with any development environment 


that supports DLLs. 











For sound, Smacker has built-in support for the Miles Sound System 
for DOS and Windows, DirectSound for Windows 95 and NT, the 
Windows waveOut system, HMI’s SOS library for DOS, 
Diamondware’s STK, and Sound Manager for the Macintosh. 


FREE}! 
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Smacker supports Watcom C for DOS, any development system that 
supports DLLs for Windows (Visual C++, Borland C, Watcom C, 

Borland Delphi, etc.), and CodeWarrior for Macintosh. There is also a 
full-featured Smacker Xtra for Macromedia Director. 
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veb-site for title lists! 


